Re: Automatically parsing in-line composite types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mitar <mmitar(at)gmail(dot)com>
Cc: f(dot)venchiarutti(at)ocado(dot)com, Dave Cramer <pg(at)fastcrypt(dot)com>, "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 18:33:00
Message-ID: 31567.1572373980@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Mitar <mmitar(at)gmail(dot)com> writes:
> I think RowDescription should be extended to provide full recursive
> metadata about all data types. That would be the best way to do it.

[ shrug... ] In a world where stability of the wire protocol were
of zero value, maybe we would do that. In the real world, don't
hold your breath.

Note that dealing with composite values in full generality is by no
means just a problem of getting this metadata. Clients would also
have to be prepared to parse and de-escape the data representation,
which is not trivial in either text or binary cases.

On the whole I think it's generally better practice to explode your
composite types into separate fields for transmission to the client.

Note that the cases where JSON or XML shine are where you don't
necessarily have a consistent set of fields in different instances
of the composite values. Even if we did extend RowDescription to
support describing composites' sub-fields, it wouldn't be in
much of a position to deal with that.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mitar 2019-10-30 02:38:29 Re: Automatically parsing in-line composite types
Previous Message Mitar 2019-10-29 17:58:22 Re: Automatically parsing in-line composite types