Horton

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

Dave Cramer <davecramer@gmail.com>

View thread
From: Dave Cramer <davecramer@gmail.com>
To: Jelte Fennema <postgres@jeltef.nl>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, Merlin Moncure <mmoncure@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-10T12:24:28Z
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 Mon, 9 Oct 2023 at 17:11, Jelte Fennema <postgres@jeltef.nl> wrote:

> On Mon, 9 Oct 2023 at 21:08, Dave Cramer <davecramer@gmail.com> wrote:
> > So if we use <schema>.<type> would it be possible to have something like
> <builtin> which represents a set of well known types?
> > My goal here is to reduce the overhead of naming all the types the
> client  wants in binary. The list of well known types is pretty long.
> > Additionally we could have a shorthand for removing a well known type.
>
> You're only setting this once in the lifetime of the connection right,
>

Correct

> i.e. right at the start (although pgbouncer could set it once per
> transaction in the worst case). It seems like it shouldn't really
> matter much to optimize the size of the "SET format_binary=..."
> command, I'd expect it to be at most 1 kilobyte. I'm not super opposed
> to having a shorthand for some of the most commonly wanted built-in
> types, but then we'd need to decide on what those are, which would add
> even more discussion/bikeshedding to this thread. I'm not sure the win
> in size is worth that effort.
>
It's worth the effort if we use schema.typename, if we use oids then I'm
not that invested in this approach.

Dave