On Fri, May 19, 2023 at 1:42 AM David G. Johnston <david.g.johnston@xxxxxxxxx> wrote:
On Thu, May 18, 2023 at 10:06 PM Raymond Brinzer <ray.brinzer@xxxxxxxxx> wrote:How do I turn arrays into composite typed values?Using just SQL syntax and no string munging:(array_val[1]::col1_type, array_val[2]::col2_type)::composite_type
None of what you are saying is likely to ever see the light of day. If you want to learn the SQL-way might be easier to just forget about your idealized equivalency between composite types and array containers.
The problem with "easier" is that addressing directly in front of you is always easier in the immediate sense than actually attacking the problem itself. It also dooms you to the (after)life of Sisyphus, always rolling the same rock up the same hill.
ARRAY[...] is a constructor, its output is an array container. You can either type the elements within the constructor or leave them untyped and put a syntactical-sugar cast on the result.ARRAY['2023-01-01'::date,'2023-02-01'::date]ARRAY['2023-01-01','2023-02-01']::date[]While you've said that having all this stuff would "be quite handy" that isn't obvious to me. It is even less obvious that any benefit would likely be small compared to the effort to make all of this actually work.
Well, making one small part of it work would be a boon to me. Is a simple, generic cast from an array to a record really rocket science? I can't imagine why that would be.
Even if I could write: composite_type[1] instead of composite_type.column1 I don't know why I'd want to give up the expressiveness of writing the column name.
Naturally, you wouldn't give up the ability to do that. You'd merely gain the ability to do it another way.
--
Ray Brinzer
