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
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 |