Re: Automatically parsing in-line composite types

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Wed, Oct 30, 2019 at 5:41 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Hm. Wouldn't it be fairly easy to allow the client to specify how much
>> metadata they'd want? I.e. opt-in into getting more complete metadata?

> Suppose you had a set of 1000 records, with an array of composites (10
> items per array). How many times would the extra metadata describing
> get sent following this approach?

Presumably once per Describe request (or once per simple Query) ...
but that facile answer actually isn't very satisfactory. It's
at least theoretically possible that a column of type "record" could
have varying actual rowtype from one tuple to the next. I don't want
to swear that every part of Postgres is capable of coping with that,
but a lot is --- see record_out() itself for the prototypical coding
pattern. The wire protocol is really pretty tightly bound to the
assumption that every tuple in a resultset has the same description,
but that's going to fall down if we want to transmit details about
what "record" means.

The same problem occurs with arrays, specifically anyarray --- and
here I don't have to think hard to come up with a query that will
break it. "select * from pg_stats" is enough to do that.

It's not only the wire protocol that's going to have issues with
varying rowtypes. How would we deal with that in libpq's resultset
API, for example? I wonder whether the JDBC API could handle it either.

tl;dr: there are a lot more worms in this can than you might guess.

regards, tom lane