Re: Automatically parsing in-line composite types - Mailing list pgsql-general

From Fabio Ugo Venchiarutti
Subject Re: Automatically parsing in-line composite types
Date
Msg-id e72efb14-4015-5820-850b-8b8ae14de7bd@ocado.com
Whole thread Raw
In response to Re: Automatically parsing in-line composite types  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: Automatically parsing in-line composite types
List pgsql-general
On 29/10/2019 12:23, Dave Cramer wrote:
> 
> 
> On Wed, 23 Oct 2019 at 15:50, Mitar <mmitar@gmail.com 
> <mailto:mmitar@gmail.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@postgresintl.com <mailto:davec@postgresintl.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.



pgsql-general by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Automatically parsing in-line composite types
Next
From: Mitar
Date:
Subject: Re: Automatically parsing in-line composite types