Hi! On Tue, Oct 29, 2019 at 11:33 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > [ 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.
Oh, yes. I would hope this would be possible in backwards compatible way. I am not too familiar with the wire protocol to know the answer to that though. > 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. Yes, but currently they cannot be prepared. They simply lack necessary information. So if they are not prepared, then the state is the same as it is currently: they get some composite type in its encoded representation as a value. But if they are prepared, they have necessary metadata to parse it. > On the whole I think it's generally better practice to explode your > composite types into separate fields for transmission to the client. The issue here is that it is really hard to make a general client for PostgreSQL. User might want to an arbitrary SQL query. I would like to be able to parse that automatically, without user having to specify additional how to parse it, or requiring them to change SQL query, or showing them encoded representation directly (not very user friendly). I agree that in simple cases one could just change the SQL query, but that is not really always possible. For example, aggregating into an array a related table is very useful because it makes amount of data transmitted over the wire much smaller (instead of having to repeat again and again contents of rows of main table). > 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. Yes, but that case is already handled: you just have a column type "JSON' (or "JSONB") and it is clear how to automatically parse that. What I am missing is a way to automatically parse composite types. Those are generally not completely arbitrary, but are defined by the query, not by data. What would be the next step to move this further in some direction? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
