From: | Mitar <mmitar(at)gmail(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Automatically parsing in-line composite types |
Date: | 2019-10-29 17:52:38 |
Message-ID: | CAKLmikMp3z29F4OPjkyHc-qbcwhSx_OFXBz5bPFoa=-vqufR7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi!
On Tue, Oct 29, 2019 at 5:23 AM Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> Reading the RowDescription is the only way I am aware of.
But that provides only the types for the top-level fields. Not the
inline composite types. If your top-level field is a registered
composite type then yes, it works out if you then go and read from
system tables definitions of those types. But for any other case where
you for example subselect a list of columns from a table in a
sub-query, it does not work out.
I think ideally, with introduction of composite types into PostgreSQL,
RowDescription should have been extended to provide information for
composite types as well, recursively. In that way you would not even
have to go and fetch additional information from other types,
potentially hitting race conditions.
Mitar
From | Date | Subject | |
---|---|---|---|
Next Message | Mitar | 2019-10-29 17:58:22 | Re: Automatically parsing in-line composite types |
Previous Message | Fabio Ugo Venchiarutti | 2019-10-29 16:06:24 | Re: Automatically parsing in-line composite types |