Re: Automatically parsing in-line composite types

Hi! On Tue, Oct 29, 2019 at 11:33 AM Tom Lane 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

Re: Automatically parsing in-line composite types

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

Re: Automatically parsing in-line composite types

Hi! On Tue, Oct 29, 2019 at 9:06 AM Fabio Ugo Venchiarutti wrote: > You can use subqueries and array_agg() to deepen your output tree all > the way to a stack overflow, a single _to_json() call at the > top will recursively traverse and convert whatever you feed it. Yes, what you are describing

Re: Automatically parsing in-line composite types

Hi! On Tue, Oct 29, 2019 at 5:23 AM Dave Cramer wrote: > Reading the RowDescription is the only way I am aware of. But that provides only the types for the top-level fields. Not the inline composite types. If your top-level field is a registered composite type then yes, it works out if you then

Re: Automatically parsing in-line composite types

On 29/10/2019 12:23, Dave Cramer wrote: On Wed, 23 Oct 2019 at 15:50, Mitar > 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

Re: Automatically parsing in-line composite types

On Wed, 23 Oct 2019 at 15:50, Mitar 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

Re: PostgreSQL - unrecognized win32 error code: 38

On Tue, Oct 29, 2019 at 9:23 PM ZhenHua Cai wrote: > No, it doesn't call any in-core code. I wondered if this could be coming from the new code in src/port/pg_p{read,write}.c. ERROR_HANDLE_EOF is a documented GetLastError() return value after ReadFile() fails[1], but only for asynchronous files.

Re: PostgreSQL - unrecognized win32 error code: 38

No, it doesn't call any in-core code. The following is the code in that function DROP TABLE IF EXISTS "GenericReadList" ; CREATE TEMP TABLE "GenericReadList"( "ComputerProfileId" int NOT NULL, "Trustee" uuid NOT NULL, "AccessControlType" smallint NULL, "AceOrder" int NULL ); INSERT INTO "GenericR