From: | Fabio Ugo Venchiarutti <f(dot)venchiarutti(at)ocado(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com>, Mitar <mmitar(at)gmail(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 16:06:24 |
Message-ID: | e72efb14-4015-5820-850b-8b8ae14de7bd@ocado.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 29/10/2019 12:23, Dave Cramer wrote:
>
>
> On Wed, 23 Oct 2019 at 15:50, Mitar <mmitar(at)gmail(dot)com
> <mailto:mmitar(at)gmail(dot)com>> wrote:
>
> Hi!
>
> Bump my previous question. I find it surprising that it seems this
> information is not possible to be reconstructed by the client, when
> the server has to have it internally. Is this a new feature request or
> am I missing something?
>
> > I am trying to understand how could I automatically parse an in-line
> > composite type. By in-line composite type I mean a type corresponding
> > to ROW. For example, in the following query:
> >
> > SELECT _id, body, (SELECT array_agg(ROW(comments._id, comments.body))
> > FROM comments WHERE comments.post_id=posts._id) AS comments FROM
> posts
> >
> > It looks like I can figure out that "comments" is an array of
> records.
> > But then there is no way really to understand how to parse those
> > records? So what are types of fields in the record?
> >
> > I start the parsing process by looking at types returned in
> > RowDescription message and then reading descriptions in pg_type
> table.
> >
> > Is there some other way to get full typing information of the
> result I
> > am assuming is available to PostreSQL internally?
>
>
>
> Reading the RowDescription is the only way I am aware of.
>
>
> Dave Cramer
>
> davec(at)postgresintl(dot)com <mailto:davec(at)postgresintl(dot)com>
> www.postgresintl.com <http://www.postgresintl.com>
Perhaps I misunderstood your question, but that sounds like my average
use-case for the object-relational type system & JSON/JSONB
functions/types: defining nested structured types as temporary relations
in my queries and spew out their hierarchical JSON representation -
often as a single big field (ironically I hate storing JSON in
relational databases unless I'm storing something really opaque like
dashboard layouts).
EG:
SELECT
t.relname AS t_name,
array_to_json(ARRAY_AGG(ats)) AS fields_json
FROM
pg_class AS t INNER JOIN (
SELECT
ia.attrelid AS table_id,
ia.attnum AS column_number,
ia.attname AS column_name
FROM
pg_attribute AS ia
) AS ats
ON
(t.relkind = 'r')
AND
(t.relname IN ('pg_type', 'pg_constraint'))
AND
(ats.table_id = t.oid)
GROUP BY
t.relname
You can use subqueries and array_agg() to deepen your output tree all
the way to a stack overflow, a single <whatever>_to_json() call at the
top will recursively traverse and convert whatever you feed it.
In your case you can just emit your composite type as a JSON object or
array thereof (types and relations are the same thing).
--
Regards
Fabio Ugo Venchiarutti
OSPCFC Network Engineering Dpt.
Ocado Technology
--
Notice:
This email is confidential and may contain copyright material of
members of the Ocado Group. Opinions and views expressed in this message
may not necessarily reflect the opinions and views of the members of the
Ocado Group.
If you are not the intended recipient, please notify us
immediately and delete all copies of this message. Please note that it is
your responsibility to scan this message for viruses.
References to the
"Ocado Group" are to Ocado Group plc (registered in England and Wales with
number 7098618) and its subsidiary undertakings (as that expression is
defined in the Companies Act 2006) from time to time. The registered office
of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way,
Hatfield, Hertfordshire, AL10 9UL.
From | Date | Subject | |
---|---|---|---|
Next Message | Mitar | 2019-10-29 17:52:38 | Re: Automatically parsing in-line composite types |
Previous Message | Dave Cramer | 2019-10-29 12:23:39 | Re: Automatically parsing in-line composite types |