> On 21 Mar 2023, at 14:44, Mark Wong wrote:
>
> On Mon, Mar 20, 2023 at 01:37:57PM -0400, Gregory Stark (as CFM) wrote:
>> On Mon, 23 Jan 2023 at 11:54, Mark Wong wrote:
>> fficient way to communicate useful information.
>>>
>>> Yeah, I will try to cover all the data types we ship. :) I'll
On Mon, Mar 20, 2023 at 01:37:57PM -0400, Gregory Stark (as CFM) wrote:
> On Mon, 23 Jan 2023 at 11:54, Mark Wong wrote:
> fficient way to communicate useful information.
> >
> > Yeah, I will try to cover all the data types we ship. :) I'll keep at
> > it and drop the code examples.
>
> I
On Mon, 23 Jan 2023 at 11:54, Mark Wong wrote:
fficient way to communicate useful information.
>
> Yeah, I will try to cover all the data types we ship. :) I'll keep at
> it and drop the code examples.
I assume this isn't going to happen for this commitfest? If you think
it is then shout
On Fri, Jan 20, 2023 at 01:12:07PM -0500, Robert Haas wrote:
> On Fri, Jan 20, 2023 at 12:58 PM Tom Lane wrote:
> > I don't mind if you write something like
> >
> > A float4 value is a 4-byte IEEE single-precision floating point
> > number. It is transmitted in network byte order, so you
On Fri, Jan 20, 2023 at 12:58 PM Tom Lane wrote:
> I don't mind if you write something like
>
> A float4 value is a 4-byte IEEE single-precision floating point
> number. It is transmitted in network byte order, so you must
> convert to local byte order. (C users can do this portably
>
Mark Wong writes:
> On Thu, Nov 03, 2022 at 09:55:22AM -0400, Tom Lane wrote:
>> Perhaps a new chapter under "IV. Client Interfaces" is the right
>> place?
>>
>> If we wanted to get aggressive, we could move most of the nitpicky details
>> about datatype text formatting (e.g., the array quoting
On Thu, Nov 03, 2022 at 09:55:22AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 01.11.22 09:15, Tom Lane wrote:
> >> Agreed that the libpq manual is not the place for this, but I feel
> >> like it will also be clutter in "Data Types". Perhaps we should
> >> invent a new appendix or
On Wed, Nov 09, 2022 at 12:47:23PM -0800, Mark Wong wrote:
> I'll take a stab at adding a new chapter and share how that looks.
This thread has stalled for three weeks, so I have marked it as
returned with feedback. Once you have a new patch, please feel free
to submit it.
--
Michael
On Thu, Nov 03, 2022 at 09:55:22AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 01.11.22 09:15, Tom Lane wrote:
> >> Agreed that the libpq manual is not the place for this, but I feel
> >> like it will also be clutter in "Data Types". Perhaps we should
> >> invent a new appendix or
Peter Eisentraut writes:
> On 01.11.22 09:15, Tom Lane wrote:
>> Agreed that the libpq manual is not the place for this, but I feel
>> like it will also be clutter in "Data Types". Perhaps we should
>> invent a new appendix or the like? Somewhere near the wire protocol
>> docs seems sensible.
On 01.11.22 09:15, Tom Lane wrote:
Peter Eisentraut writes:
If we want to start documenting the binary format for all data types, it
should go into the "Data Types" chapter. There, we already document the
text format in great detail, so putting the binary format in there as
well would make
Peter Eisentraut writes:
> If we want to start documenting the binary format for all data types, it
> should go into the "Data Types" chapter. There, we already document the
> text format in great detail, so putting the binary format in there as
> well would make sense.
Agreed that the libpq
On 01.07.22 19:18, Mark Wong wrote:
Just wanted to do another quick check in before I go too far. How do
does this start look? Extending the libpq section with a code snippet
and description per data type?
If we want to start documenting the binary format for all data types, it
should go
On Thu, Jun 16, 2022 at 03:41:50PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jun 14, 2022 at 1:40 PM Mark Wong wrote:
> >> I've created a function for each data type with the idea that an example
> >> for handling a specific data type can be more easily reviewed by looking
> >> in
On Thu, Jun 16, 2022 at 03:41:50PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jun 14, 2022 at 1:40 PM Mark Wong wrote:
> >> I've created a function for each data type with the idea that an example
> >> for handling a specific data type can be more easily reviewed by looking
> >> in
Robert Haas writes:
> On Tue, Jun 14, 2022 at 1:40 PM Mark Wong wrote:
>> I've created a function for each data type with the idea that an example
>> for handling a specific data type can be more easily reviewed by looking
>> in a single place.
>> I've added examples for REAL, TIMESTAMP WITHOUT
On Tue, Jun 14, 2022 at 1:40 PM Mark Wong wrote:
> Checking in for quick feedback to see if this refactor makes sense.
>
> I've created a function for each data type with the idea that an example
> for handling a specific data type can be more easily reviewed by looking
> in a single place.
>
>
On Wed, Mar 30, 2022 at 01:16:37PM -0400, Greg Stark wrote:
> On Mon, 28 Feb 2022 at 17:50, Tom Lane wrote:
> >
> > Chapman Flack writes:
> > > In the current state of affairs, what's considered the ur-source of that
> > > information?
> >
> > The source code for the type's send/receive
On Mon, 28 Feb 2022 at 17:50, Tom Lane wrote:
>
> Chapman Flack writes:
> > In the current state of affairs, what's considered the ur-source of that
> > information?
>
> The source code for the type's send/receive functions :-(. One could
> wish for something better, but no one has stepped up
Chapman Flack writes:
> This stimulates a question for me.
> Not just libpq, but all drivers implemented in whatever language, if they
> wish to support binary protocol, depend on knowing what the committed
> send/recv wire formats are for whichever types they mean to support.
> In the current
On 02/28/22 10:19, Tom Lane wrote:
>> That will standardize the
>> way to fetch real typed values in libpq. That leads to the next
>> question. Do we need to introduce different PQget*value() for standard
>> C/SQL data types.
>
> ... I do not want to go here. Where would you stop? How would you
Ashutosh Bapat writes:
> I am wondering whether we should provide PQgetfloatvalue() which does
> what that example shows but transparently. It will return a float
> value of the given field instead of char *.
I'm against that, precisely because ...
> That will standardize the
> way to fetch
Hi Mark,
Fetching a "real" type field from libpq doesn't look that intuitive.
So this example is super helpful. Thanks.
I am wondering whether we should provide PQgetfloatvalue() which does
what that example shows but transparently. It will return a float
value of the given field instead of char
Hi everyone,
Would adding additional examples to testlibpq3.c on handling more data
types be helpful? I've attached a patch adding how to handle a REAL to
current example.
Regards,
Mark
diff --git a/src/test/examples/testlibpq3.c b/src/test/examples/testlibpq3.c
index 4f7b791388..0c1739fcbb
24 matches
Mail list logo
