Re: default result formats setting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: default result formats setting
Date
Msg-id 1057459.1616597886@sss.pgh.pa.us
Whole thread Raw
In response to Re: default result formats setting  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: default result formats setting  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> But ... if it's just a GUC, it can be set by code on the server side
> that the client knows nothing about, breaking the client. That seems
> pretty bad to me.

It's impossible for the proposed patch to break *existing* clients,
because they all send requested format 0 or 1, and that is exactly
what they'll get back.

A client that is sending -1 and assuming that it will get back
a particular format could get broken if the GUC doesn't have the
value it thinks, true.  But I'd argue that such code is unreasonably
non-robust.  Can't we solve this by recommending that clients using
this feature always double-check which format they actually got?
ISTM that the use-cases for the feature involve checking what data
type you got anyway, so that's not an unreasonable added requirement.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Custom compression methods