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: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-04-18T16:31:14Z
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 Tue, 18 Apr 2023 at 12:24, Robert Haas <robertmhaas@gmail.com> wrote:

> On Tue, Apr 18, 2023 at 11:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> > > One thing I think we should do in this area is introduce #defines for
> > > all the message type codes and use those instead of having hard-coded
> > > constants everywhere.
> >
> > +1, but I wonder where we should put those exactly.  My first thought
> > was postgres_ext.h, but the charter for that is
> >
> >  *     This file contains declarations of things that are visible
> everywhere
> >  *  in PostgreSQL *and* are visible to clients of frontend interface
> libraries.
> >  *  For example, the Oid type is part of the API of libpq and other
> libraries.
> >
> > so picayune details of the wire protocol probably don't belong there.
> > Maybe we need a new header concerned with the wire protocol?
>
> Yeah. I sort of thought maybe one of the files in src/include/libpq
> would be the right place, but it doesn't look like it.
>
> If we at least created the defines and replaced occurrences with the same,
then we can litigate where to put them later.

I think I'd prefer this in a different patch, but I'd be willing to take a
run at it.

Dave