Re: Records, Types, and Arrays

From: Raymond Brinzer <ray(dot)brinzer(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Records, Types, and Arrays
Date: 2023-05-19 06:16:58
Message-ID: CANasJHmAOiQ7BEnRvdfExBFPq-A0Hapwb=H5nvkGk9wdbJaykA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, May 19, 2023 at 1:42 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Thu, May 18, 2023 at 10:06 PM Raymond Brinzer <ray(dot)brinzer(at)gmail(dot)com>
> 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
>

Assuming one wants to write a specific solution, rather than a general one,
sure. And when you want to deal with an unnamed array returned from a
function? Well, you can throw *that* in a CTE to give it a name, or
perform some other such contortion. The aggregate load of having to phrase
such simple ideas in complicated ways really isn't good.
>
>
> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Maciek Sakrejda 2023-05-19 06:33:11 Re: pg_stats.avg_width
Previous Message David G. Johnston 2023-05-19 05:42:01 Re: Records, Types, and Arrays