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

On Sat, 27 Jan 2024 at 07:45, vignesh C wrote: > > On Mon, 31 Jul 2023 at 21:58, Dave Cramer wrote: > > > > > > Dave Cramer > > > > > > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson wrote: > >> > >> > On 25 Apr 2023, at 16:47, Dave Cramer wrote: > >> > >> > Patch attached with comments

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

On Mon, 31 Jul 2023 at 21:58, Dave Cramer wrote: > > > Dave Cramer > > > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson wrote: >> >> > On 25 Apr 2023, at 16:47, Dave Cramer wrote: >> >> > Patch attached with comments removed >> >> This patch no longer applies, please submit a rebased version

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

On Tue, Oct 10, 2023 at 10:30 AM Dave Cramer wrote: > Correct me if I am wrong, but the client has to request this. So I'm not sure > how we would be surprised ? Consider an application, a connection pooler, and a stored procedure or function on the server. If this is controlled by a GUC, any

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

On Mon, Oct 9, 2023 at 5:02 PM Jelte Fennema wrote: > Honestly I think the main difference is the need to introduce this > explicit protocol message. If we do, I think it might be best to have > this be a way of setting a GUC at the Protocol level, and expand the > GucContext enum to have a way

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

On Tue, 10 Oct 2023 at 10:25, Robert Haas wrote: > On Mon, Oct 9, 2023 at 4:25 PM Jeff Davis wrote: > > Another thing to consider is that using a GUC for binary formats is a > > protocol change in a way that client_encoding is not. The existing > > documentation for the protocol already

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

On Mon, Oct 9, 2023 at 4:25 PM Jeff Davis wrote: > Another thing to consider is that using a GUC for binary formats is a > protocol change in a way that client_encoding is not. The existing > documentation for the protocol already specifies when binary formats > will be used, and a GUC would

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

On Mon, 9 Oct 2023 at 17:11, Jelte Fennema wrote: > On Mon, 9 Oct 2023 at 21:08, Dave Cramer wrote: > > So if we use . would it be possible to have something like > which represents a set of well known types? > > My goal here is to reduce the overhead of naming all the types the > client

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

On Mon, 9 Oct 2023 at 21:08, Dave Cramer wrote: > So if we use . would it be possible to have something like > 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

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

On Mon, 9 Oct 2023 at 22:25, Jeff Davis wrote: > We absolutely would > need to update the documentation, and clients (like psql) really should > be updated. +1 > > I think one > > could conclude on these facts either that (a) client_encoding is fine > > and the problems with controlling

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

On Mon, 9 Oct 2023 at 21:00, Robert Haas wrote: > ...but then... > > > With Citus the same user defined type can have > > different OIDs on each of the servers in the cluster. > > I realize that your intention here may be to say that this is not an > *additional* problem but one we have already.

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

On Wed, 2023-10-04 at 15:10 -0400, Robert Haas wrote: > I hadn't really considered client_encoding as a precedent for this > setting. A lot of my discomfort with the proposed mechanism also > applies to client_encoding, namely, suppose you call some function or > procedure or whatever and it

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

On Mon, 9 Oct 2023 at 15:00, Robert Haas wrote: > On Mon, Oct 9, 2023 at 11:09 AM Jelte Fennema wrote: > > Since the protocol already returns OIDs in the ParameterDescription > > and RowDescription messages I don't see why using OIDs for this GUC > > would cause any additional problems. > >

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

On Mon, Oct 9, 2023 at 11:09 AM Jelte Fennema wrote: > Since the protocol already returns OIDs in the ParameterDescription > and RowDescription messages I don't see why using OIDs for this GUC > would cause any additional problems. ...but then... > With Citus the same user defined type can have

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

On Fri, 6 Oct 2023 at 13:11, Peter Eisentraut wrote: > > On 04.10.23 20:30, Dave Cramer wrote: > > We need to > > figure out what is the right way to globally identify types, like > > either > > by fully-qualified name, by base name, some combination, how does it > > work with

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

On Wed, 4 Oct 2023 at 21:10, Robert Haas wrote: > > On Wed, Oct 4, 2023 at 10:17 AM Peter Eisentraut wrote: > > I think intuitively, this facility ought to work like client_encoding. > > I hadn't really considered client_encoding as a precedent for this > setting. A lot of my discomfort with the

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

On 04.10.23 21:10, Robert Haas wrote: On Wed, Oct 4, 2023 at 10:17 AM Peter Eisentraut wrote: I think intuitively, this facility ought to work like client_encoding. I hadn't really considered client_encoding as a precedent for this setting. A lot of my discomfort with the proposed mechanism

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

On 04.10.23 20:30, Dave Cramer wrote: We need to figure out what is the right way to globally identify types, like either by fully-qualified name, by base name, some combination, how does it work with extensions, or do we need a new mechanism like UUIDs.  I think that

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

On 04.10.23 18:26, Merlin Moncure wrote: On Wed, Oct 4, 2023 at 9:17 AM Peter Eisentraut > wrote: I think intuitively, this facility ought to work like client_encoding. There, the client declares its capabilities, and the server has to format the output

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

On Wed, Oct 4, 2023 at 10:17 AM Peter Eisentraut wrote: > I think intuitively, this facility ought to work like client_encoding. I hadn't really considered client_encoding as a precedent for this setting. A lot of my discomfort with the proposed mechanism also applies to client_encoding, namely,

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

On Wed, 4 Oct 2023 at 10:17, Peter Eisentraut wrote: > On 31.07.23 18:27, Dave Cramer wrote: > > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson > > wrote: > > > > > On 25 Apr 2023, at 16:47, Dave Cramer > > wrote: > > > > >

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

On Wed, Oct 4, 2023 at 9:17 AM Peter Eisentraut wrote: > I think intuitively, this facility ought to work like client_encoding. > There, the client declares its capabilities, and the server has to > format the output according to the client's capabilities. That works, > and it also works

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

On 31.07.23 18:27, Dave Cramer wrote: On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson > wrote: > On 25 Apr 2023, at 16:47, Dave Cramer mailto:davecra...@gmail.com>> wrote: > Patch attached with comments removed This patch no longer applies, please submit

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

Dave Cramer On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson wrote: > > On 25 Apr 2023, at 16:47, Dave Cramer wrote: > > > Patch attached with comments removed > > This patch no longer applies, please submit a rebased version on top of > HEAD. > Rebased see attached > > -- > Daniel

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

> On 25 Apr 2023, at 16:47, Dave Cramer wrote: > Patch attached with comments removed This patch no longer applies, please submit a rebased version on top of HEAD. -- Daniel Gustafsson

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

On Tue, 25 Apr 2023 at 07:26, Dave Cramer wrote: > > > > On Mon, 24 Apr 2023 at 19:18, Merlin Moncure wrote: > >> >> >> On Thu, Apr 20, 2023 at 2:52 PM Dave Cramer wrote: >> >>> >>> As promised here is a patch with defines for all of the protocol >>> messages. >>> >> I created a protocol.h

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

On Mon, 24 Apr 2023 at 19:18, Merlin Moncure wrote: > > > On Thu, Apr 20, 2023 at 2:52 PM Dave Cramer wrote: > >> >> As promised here is a patch with defines for all of the protocol messages. >> > I created a protocol.h file and put it in src/includes >> I'm fairly sure that some of the names I

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

On Thu, Apr 20, 2023 at 2:52 PM Dave Cramer wrote: > > As promised here is a patch with defines for all of the protocol messages. > I created a protocol.h file and put it in src/includes > I'm fairly sure that some of the names I used may need to be changed but > the grunt work of finding and

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

> > > > > Backing up a level, the purpose of the protocol extension mechanism is > to help us agree on the communication protocol -- that is, the set of > messages that we can send and receive on a certain connection. The > question for the protocol extension mechanism isn't "which types > should

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

On Tue, 18 Apr 2023 at 12:31, Dave Cramer wrote: > > > On Tue, 18 Apr 2023 at 12:24, Robert Haas wrote: > >> On Tue, Apr 18, 2023 at 11:51 AM Tom Lane wrote: >> > Robert Haas writes: >> > > One thing I think we should do in this area is introduce #defines for >> > > all the message type codes

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

On Tue, Apr 18, 2023 at 3:54 PM Greg Stark wrote: > Well the way I understood Robert's proposal would be that you would > set a protocol option which could be some name like > SuperDuperExtension and then later send an extended message like X > SuperDuper Extension ... > > The point being not so

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

On Mon, 17 Apr 2023 at 16:22, Tom Lane wrote: > > I tend to agree with the proposition that we aren't going to add new > message types very often, as long as we're careful to make them general > purpose. Don't forget that adding a new message type isn't just a matter > of writing some spec text

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

On Tue, 18 Apr 2023 at 12:24, Robert Haas wrote: > On Tue, Apr 18, 2023 at 11:51 AM Tom Lane wrote: > > Robert Haas 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

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

On Tue, Apr 18, 2023 at 11:51 AM Tom Lane wrote: > Robert Haas 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

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

Robert Haas 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

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

On Mon, Apr 17, 2023 at 4:22 PM Tom Lane wrote: > The fact that we've gotten away without adding *any* new message types > for about twenty years suggests to me that the growth rate isn't such > that we need sub-message-types yet. I'd keep the structure the same > until such time as we can't

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

Robert Haas writes: > On Mon, Apr 17, 2023 at 1:55 PM Jeff Davis wrote: >> Maybe we should have a single new message type 'x' to indicate a >> message for a protocol extension, and then have a sub-message-type? It >> might make error handling better for unexpected messages. > ... > The point of

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

On Mon, Apr 17, 2023 at 1:55 PM Jeff Davis wrote: > It involves introducing new message types which I didn't really > consider. We might want to be careful about how many kinds of messages > we introduce so that the one-letter codes are still managable. I've > been frustrated in the past that we

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

On Mon, 2023-04-17 at 12:17 -0400, Robert Haas wrote: > In the case at hand, it seems like the problem could easily be solved > by allowing the property to be changed after connection startup. > Instead of using the protocol extension mechanism to negotiate a > specific value for the property, we

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

On Wed, Mar 29, 2023 at 12:04 PM Jeff Davis wrote: > I'm starting to agree that the awkwardness around connection poolers is > a problem. If that's the case, I'm wondering if the protocol extensions > will ever be useful. In the case at hand, it seems like the problem could easily be solved by

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

On Mon, Apr 3, 2023 at 11:29 AM Dave Cramer wrote: > > participating clients to receive GUC configured format. I do not > >> > think that libpq's result format being able to be overridden by GUC >>> > is a good idea at all, the library has to to participate, and I >>> > think can be made to so

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

> participating clients to receive GUC configured format. I do not > > think that libpq's result format being able to be overridden by GUC >> > is a good idea at all, the library has to to participate, and I >> > think can be made to so so without adjusting the interface (say, by >> >

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

Dave Cramer On Thu, 30 Mar 2023 at 15:40, Jeff Davis wrote: > On Thu, 2023-03-30 at 07:06 -0500, Merlin Moncure wrote: > > This ought to be impossible IMO. All libpq routines except PQexec > > have an explicit expectation on format (via resultformat parameter) > > that should not be

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

On Thu, 2023-03-30 at 07:06 -0500, Merlin Moncure wrote: > This ought to be impossible IMO.  All libpq routines except PQexec > have an explicit expectation on format (via resultformat parameter) > that should not be overridden.  PQexec ought to be explicitly > documented and wired to only request

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

On Wed, Mar 29, 2023 at 11:04 AM Jeff Davis wrote: > I'm not clear on what proposal you are making and/or endorsing? > ha -- was just backing up dave's GUC idea. > 1. Fix our own clients, like psql, to check for binary data they can't > process. > This ought to be impossible IMO. All libpq

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

On Wed, 2023-03-29 at 08:17 -0400, Dave Cramer wrote: > I'm starting to wonder about the utility of the protocol extension > mechanism?  I'm starting to agree that the awkwardness around connection poolers is a problem. If that's the case, I'm wondering if the protocol extensions will ever be

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

On Tue, 28 Mar 2023 at 19:01, Jeff Davis wrote: > On Tue, 2023-03-28 at 10:22 -0400, Dave Cramer wrote: > > OK, IIUC what you are proposing here is that there would be a > > separate pool for > > database, user, and OIDs. This doesn't seem too flexible. For > > instance if I create a UDT and

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

On Tue, 2023-03-28 at 10:22 -0400, Dave Cramer wrote: > OK, IIUC what you are proposing here is that there would be a > separate pool for  > database, user, and OIDs. This doesn't seem too flexible. For > instance if I create a UDT and then want it to be returned  > as binary then I have to

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

FYI I attached this thread to https://commitfest.postgresql.org/42/3777 which I believe is the same issue. I mistakenly had this listed as a CF entry with no discussion for a long time due to that missing link. -- Gregory Stark As Commitfest Manager

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

On Sun, 26 Mar 2023 at 21:30, Tom Lane wrote: > Dave Cramer writes: > > On Sun, 26 Mar 2023 at 18:12, Tom Lane wrote: > >> I would not expect DISCARD ALL to reset a session-level property. > > > Well if we can't reset it with DISCARD ALL how would that work with > > pgbouncer, or any pool for

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

Dave Cramer writes: > On Sun, 26 Mar 2023 at 18:12, Tom Lane wrote: >> I would not expect DISCARD ALL to reset a session-level property. > Well if we can't reset it with DISCARD ALL how would that work with > pgbouncer, or any pool for that matter since it doesn't know which client > asked for

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

Dave Cramer On Sun, 26 Mar 2023 at 18:12, Tom Lane wrote: > Dave Cramer writes: > > Well I was presuming that they would just pass the parameter on. If they > > didn't then binary_format won't work with them. In the case that they do > > pass it on, then DISCARD_ALL will reset it and future

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

Dave Cramer writes: > Well I was presuming that they would just pass the parameter on. If they > didn't then binary_format won't work with them. In the case that they do > pass it on, then DISCARD_ALL will reset it and future borrows of the > connection will have no way to set it again;

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

On Sun, 26 Mar 2023 at 14:00, Jeff Davis wrote: > On Sat, 2023-03-25 at 19:58 -0400, Dave Cramer wrote: > > Well that means that connection poolers have to all be fixed. There > > are more than just pgbouncer. > > Seems rather harsh that a new feature breaks a connection pooler or > > makes the

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

On Sat, 2023-03-25 at 19:58 -0400, Dave Cramer wrote: > Well that means that connection poolers have to all be fixed. There > are more than just pgbouncer. > Seems rather harsh that a new feature breaks a connection pooler or > makes the pooler unusable. Would it actually break connection poolers

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

Dave Cramer On Sat, 25 Mar 2023 at 19:06, Jeff Davis wrote: > On Thu, 2023-03-23 at 15:37 -0400, Dave Cramer wrote: > > So where do we go from here ? > > > > I can implement using type names as well as OID's > > My current thought is that you should use the protocol extension and > make type

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

On Thu, 2023-03-23 at 15:37 -0400, Dave Cramer wrote: > So where do we go from here ? > > I can implement using type names as well as OID's My current thought is that you should use the protocol extension and make type names work (in addition to OIDs) at least for fully-qualified type names. I

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

On Fri, 2023-03-24 at 07:52 -0500, Merlin Moncure wrote: > I think so.  Dave's idea puts a lot of flexibility into the client > side, and that's good.  Search path mechanics are really well > understood and well integrated with extensions already (create > extension ..schema) assuming that the

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

On Tue, Mar 21, 2023 at 4:47 PM Jeff Davis wrote: > On Tue, 2023-03-21 at 09:22 -0400, Dave Cramer wrote: > > As Jeff mentioned there is a visibility problem if the search path is > > changed. The simplest solution IMO is to look up the OID at the time > > the format is requested and use the OID

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

On Wed, 22 Mar 2023 at 15:23, Jeff Davis wrote: > On Wed, 2023-03-22 at 14:42 -0400, Tom Lane wrote: > > This isn't going to help much unless we change the wire protocol > > so that RowDescription messages carry these UUIDs instead of > > (or in addition to?) the OIDs of the column datatypes.

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

On Wed, 2023-03-22 at 14:42 -0400, Tom Lane wrote: > This isn't going to help much unless we change the wire protocol > so that RowDescription messages carry these UUIDs instead of > (or in addition to?) the OIDs of the column datatypes.  While > that's not completely out of the question, it's a

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

Jeff Davis writes: > On Wed, 2023-03-22 at 10:21 +0100, Peter Eisentraut wrote: >> I've been thinking that we need some new kind of identifier to allow >> clients to process types in more sophisticated ways. >> For example, each type could be (self-)assigned a UUID, which is fixed >> for that

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

On Wed, 2023-03-22 at 10:12 +0100, Peter Eisentraut wrote: > Sending type names is kind of useless if what comes back with the > result > (RowDescription) are OIDs anyway. > > The client would presumably have some code like > > if (typeoid == 555) > parseThatType(); > > So it already

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

On Wed, 2023-03-22 at 10:21 +0100, Peter Eisentraut wrote: > I've been thinking that we need some new kind of identifier to allow > clients to process types in more sophisticated ways. > > For example, each type could be (self-)assigned a UUID, which is > fixed > for that type no matter in

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

If I recall the protocol-extension design correctly, such a setting could only be set at session start, which could be annoying --- at the very least we'd have to tolerate entries for unrecognized data types, since clients couldn't be expected to have checked the list against the current server in

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

If there's some extension that offers type "mytype", and perhaps allows it to be installed in any schema, then it seems that the client library would know how to parse all instances of "mytype" regardless of the schema or search_path. I may be overthinking this. Dave Cramer On Tue, 21 Mar 2023

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

On 20.03.23 18:04, Jeff Davis wrote: Also, if we're going to make the binary format more practical to use, can we document the expectations better? It seems the expecatation is that the binary format just never changes, and that if it does, that's a new type name. I've been thinking that we

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

On 20.03.23 18:04, Jeff Davis wrote: 2. Easy to confuse psql: CREATE TABLE a(d date, t timestamptz); SET format_binary='25,1082,1184'; SELECT * FROM a; d | t ---+--- ! | (1 row) You can already send binary data to psql using DECLARE BINARY CURSOR. It might be sensible

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

On 04.03.23 17:35, Jeff Davis wrote: On Thu, 2023-03-02 at 09:13 -0500, Dave Cramer wrote: I'd like to open up this discussion again so that we can move forward. I prefer the GUC as it is relatively simple and as Peter mentioned it works, but I'm not married to the idea. It's not very

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

On Tue, 2023-03-21 at 09:22 -0400, Dave Cramer wrote: > As Jeff mentioned there is a visibility problem if the search path is > changed. The simplest solution IMO is to look up the OID at the time > the format is requested and use the OID going forward to format the > output as binary. If the

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

On Tue, 21 Mar 2023 at 11:52, Jeff Davis wrote: > On Mon, 2023-03-20 at 20:18 -0400, Dave Cramer wrote: > > For JAVA pools it's probably OK, but for pools like pgbouncer we have > > no control of who is going to get the connection next. > > Can pgbouncer use different pools for different

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

On Mon, 2023-03-20 at 20:18 -0400, Dave Cramer wrote: > For JAVA pools it's probably OK, but for pools like pgbouncer we have > no control of who is going to get the connection next. Can pgbouncer use different pools for different settings of format_binary? Regards, Jeff Davis

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

On Tue, Mar 21, 2023 at 8:22 AM Dave Cramer wrote: > > On Tue, 21 Mar 2023 at 07:35, Merlin Moncure wrote: > >> >> >> On Mon, Mar 20, 2023 at 7:11 PM Dave Cramer wrote: >> >>> >>> >>> >>> On Mon, 20 Mar 2023 at 19:10, Merlin Moncure wrote: >>> On Mon, Mar 13, 2023 at 3:33 PM

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

On Tue, 21 Mar 2023 at 07:35, Merlin Moncure wrote: > > > On Mon, Mar 20, 2023 at 7:11 PM Dave Cramer wrote: > >> >> >> >> On Mon, 20 Mar 2023 at 19:10, Merlin Moncure wrote: >> >>> >>> >>> On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer >>> wrote: >>> OIDs are a pain to deal with IMO.

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

On Mon, Mar 20, 2023 at 7:11 PM Dave Cramer wrote: > > > > On Mon, 20 Mar 2023 at 19:10, Merlin Moncure wrote: > >> >> >> On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer wrote: >> >>> >>> OIDs are a pain to deal with IMO. They will not survive a dump style >> restore, and are hard to keep

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

On Mon, 20 Mar 2023 at 15:09, Jeff Davis wrote: > On Mon, 2023-03-20 at 14:36 -0400, Dave Cramer wrote: > > Thanks for the review. I'm curious what system you are running on as > > I don't see any of these errors. > > Are asserts enabled? > > > Well I'm guessing psql doesn't know how to read

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

Dave Cramer On Mon, 20 Mar 2023 at 15:09, Tom Lane wrote: > Dave Cramer writes: > > On Mon, 20 Mar 2023 at 13:05, Jeff Davis wrote: > >> 2. Easy to confuse psql: > >> > >> CREATE TABLE a(d date, t timestamptz); > >> SET format_binary='25,1082,1184'; > >> SELECT * FROM a; > >> d | t > >>

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

On Mon, 20 Mar 2023 at 19:10, Merlin Moncure wrote: > > > On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer wrote: > >> >> Dave Cramer >> >> >> On Sat, 4 Mar 2023 at 19:39, Dave Cramer wrote: >> >>> >>> >>> On Sat, 4 Mar 2023 at 19:06, Tom Lane wrote: >>> Jeff Davis writes: > On Sat,

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

On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer wrote: > > Dave Cramer > > > On Sat, 4 Mar 2023 at 19:39, Dave Cramer wrote: > >> >> >> On Sat, 4 Mar 2023 at 19:06, Tom Lane wrote: >> >>> Jeff Davis writes: >>> > On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote: >>> >> Most of the clients

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

On Mon, 2023-03-20 at 14:36 -0400, Dave Cramer wrote: > Thanks for the review. I'm curious what system you are running on as > I don't see any of these errors.  Are asserts enabled? > Well I'm guessing psql doesn't know how to read date or timestamptz > in binary. This is not a failing of the

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

Dave Cramer writes: > On Mon, 20 Mar 2023 at 13:05, Jeff Davis wrote: >> 2. Easy to confuse psql: >> >> CREATE TABLE a(d date, t timestamptz); >> SET format_binary='25,1082,1184'; >> SELECT * FROM a; >> d | t >> ---+--- >> ! | >> (1 row) >> >> Well I'm guessing psql doesn't know how to read

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

On Mon, 2023-03-20 at 10:04 -0700, Jeff Davis wrote: >   CREATE TABLE a(d date, t timestamptz); >   SET format_binary='25,1082,1184'; >   SELECT * FROM a; >    d | t >   ---+--- >    ! | >   (1 row) Oops, missing the following statement after the CREATE TABLE: INSERT INTO a

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

+Paul Ramsey On Mon, 20 Mar 2023 at 13:05, Jeff Davis wrote: > On Mon, 2023-03-13 at 16:33 -0400, Dave Cramer wrote: > > Attached is a preliminary patch that takes a list of OID's. I'd like > > to know if this is going in the right direction. > > Thanks for the review. I'm curious what system

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

On Mon, 2023-03-13 at 16:33 -0400, Dave Cramer wrote: > Attached is a preliminary patch that takes a list of OID's. I'd like > to know if this is going in the right direction. I found a few issues: 1. Some kind of memory error: SET format_binary='25,1082,1184'; WARNING: problem in alloc

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

Dave Cramer On Sat, 4 Mar 2023 at 19:39, Dave Cramer wrote: > > > On Sat, 4 Mar 2023 at 19:06, Tom Lane wrote: > >> Jeff Davis 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

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

On Sat, 4 Mar 2023 at 19:06, Tom Lane wrote: > Jeff Davis 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

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

On Sat, Mar 4, 2023 at 5:07 PM Tom Lane wrote: > Jeff Davis 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

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

Jeff Davis 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

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

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

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

Dave Cramer On Sat, 4 Mar 2023 at 11:35, Jeff Davis wrote: > On Thu, 2023-03-02 at 09:13 -0500, Dave Cramer wrote: > > I'd like to open up this discussion again so that we can > > move forward. I prefer the GUC as it is relatively simple and as > > Peter mentioned it works, but I'm not married

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

On Thu, 2023-03-02 at 09:13 -0500, Dave Cramer wrote: > I'd like to open up this discussion again so that we can > move forward. I prefer the GUC as it is relatively simple and as > Peter mentioned it works, but I'm not married to the idea.  It's not very friendly to extensions, where the types

Request for comment on setting binary format output per session

Greetings, In [1] I proposed a patch that used a GUC to request a list of OID's to be returned in binary format. In [2] Peter Eisentraut proposed a very similar solution to the problem. In [2] there was some discussion regarding whether this should be set via GUC or a new protocol message. I'd