Re: default result formats setting

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Steele <david(at)pgmasters(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: default result formats setting
Date: 2021-03-18 20:13:16
Message-ID: 795e29f2-678a-afde-a1c4-af0c61ad96b8@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09.03.21 19:04, Tom Lane wrote:
> The implementation feels weird though, mainly in that I don't like
> Peter's choices for where to put the code. pquery.c is not where
> I would have expected to find the support for this, and I do not
> have any confidence that applying the format conversion while
> filling portal->formats[] is enough to cover all cases. I'd have
> thought that access/common/printtup.c or somewhere near there
> would be where to do it.

done

> Or we could drop all of that and go back to having it be a list
> of type OIDs, which would remove a *whole lot* of the complexity,
> and I'm not sure that it's materially less friendly. Applications
> have had to deal with type OIDs in the protocol since forever.

also done

The client driver needs to be able to interpret the OIDs that the
RowDescription sends back, so it really needs to be able to deal in
OIDs, and having the option to specify type names won't help it right now.

> BTW, I wonder whether we still need to restrict the GUC to not
> be settable from postgresql.conf. The fact that the client has
> to explicitly pass -1 seems to reduce any security issues quite
> a bit.

There was no security concern, but I don't think it's useful. The
driver would specify "send int4 in binary, I know how to handle that".
There doesn't seem to be a point in specifying that sort of thing globally.

Attachment Content-Type Size
v4-0001-Add-result_format_auto_binary_types-setting.patch text/plain 14.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-03-18 20:46:49 Maintaining a list of pgindent commits for "git blame" to ignore
Previous Message Euler Taveira 2021-03-18 20:06:23 Re: cleanup temporary files after crash