Horton

Re: Request for comment on setting binary format output per session

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, Dave Cramer <davecramer@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-05T00:13:13Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Silence compiler warning introduced in 1edb3b491b

On Sat, Mar 4, 2023 at 5:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Jeff Davis <pgsql@j-davis.com> writes:
> > On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote:
> >> Most of the clients know how to decode the builtin types. I'm not
> >> sure there is a use case for binary encode types that the clients
> >> don't have a priori knowledge of.
>
> > The client could, in theory, have a priori knowledge of a non-builtin
> > type.
>
> I don't see what's "in theory" about that.  There seems plenty of
> use for binary I/O of, say, PostGIS types.  Even for built-in types,
> do we really want to encourage people to hard-wire their OIDs into
> applications?
>
> I don't see a big problem with driving this off a GUC, but I think
> it should be a list of type names not OIDs.  We already have plenty
> of precedent for dealing with that sort of thing; see search_path
> for the canonical example.  IIRC, there's similar caching logic
> for temp_tablespaces.
>
>
This seems slightly different since types depend upon schemas whereas
search_path is top-level and tablespaces are global.  But I agree that
names should be accepted, maybe in addition to OIDs, the latter, for core
types in particular, being a way to not have to worry about masking in
user-space.

David J.