* Tom Lane ([EMAIL PROTECTED]) wrote:
> I said:
> > I'll make a note to do something with this issue after the TZ patch
> > is in.
>
> I've applied a patch to take care of this problem.
Great, thanks, much appriciated. I'll test once 7.5 goes beta.
Stephen
signature.asc
Description: D
I said:
> I'll make a note to do something with this issue after the TZ patch
> is in.
I've applied a patch to take care of this problem.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
I wrote:
> In general we do check incoming binary values to ensure minimal
> validity. I think when I did timestamp_recv I was thinking it was
> just like int8 or float8 (respectively), in that any bit pattern is
> potentially legal; I had forgotten about the range restrictions.
> I haven't looke
Stephen Frost <[EMAIL PROTECTED]> writes:
>> How many datatype have this issue?
> I don't think that many do.. A number of them already check incoming
> values where it's possible for them to not be valid.
In general we do check incoming binary values to ensure minimal
validity. I think when I
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I wasn't aware you could throw binary values into the timestamp fields
> > like that. I thought you needed to use a C string for the value.
>
> This facility was added in 7.4 as part of the wire-protocol overhaul.
> It's nothing dire
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I wasn't aware you could throw binary values into the timestamp fields
> > > like that. I thought you needed to use a C string for the value.
> >
> > This facility was added in 7.4 as
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I wasn't aware you could throw binary values into the timestamp fields
> like that. I thought you needed to use a C string for the value.
This facility was added in 7.4 as part of the wire-protocol overhaul.
It's nothing directly to do with PREPARE; you
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Considering all the other things the database is doing, I can't imagine
> that would be a measurable improvement.
It makes it easier on my client program too which is listening to an
ethernet interface and trying to process all of the packets coming in
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> > Stephen Frost wrote:
> > > I'll see about writing up a proper test case/schema. Looks like I'm
> > > probably most of the way there at this point, really. ;)
> >
> > I wasn't aware you could thro
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > I'll see about writing up a proper test case/schema. Looks like I'm
> > probably most of the way there at this point, really. ;)
>
> I wasn't aware you could throw binary values into the timestamp fields
> like that. I thought
Stephen Frost wrote:
> > So you are passing the data via binary COPY or a C function?
>
> Sorry I wasn't clear, it's using libpq and binary data using an 'insert'
> statement. The code looks something like this:
>
> PQexec(connection,"prepare addrow (timestamp) as insert into mytable
> values ($
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> > > Would you show an example of the invalid value this is trying to avoid?
> >
> > Well, the way I discovered the problem was by sending a timestamp
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> > Would you show an example of the invalid value this is trying to avoid?
>
> Well, the way I discovered the problem was by sending a timestamp in
> double format when the server was expecting one i
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> >> Would you show an example of the invalid value this is trying to avoid?
>
> > Well, the way I discovered the problem was by sending a timestamp in
> > double format
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Bruce Momjian ([EMAIL PROTECTED]) wrote:
>> Would you show an example of the invalid value this is trying to avoid?
> Well, the way I discovered the problem was by sending a timestamp in
> double format when the server was expecting one in int64 format
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Would you show an example of the invalid value this is trying to avoid?
Well, the way I discovered the problem was by sending a timestamp in
double format when the server was expecting one in int64 format. This
is when using the binary data method for
Would you show an example of the invalid value this is trying to avoid?
---
Stephen Frost wrote:
> Greetings,
>
> The attached patch adds some error-checking to the timestamp_recv
> function so that it's not possible to
Greetings,
The attached patch adds some error-checking to the timestamp_recv
function so that it's not possible to put an invalid timestamp into a
timestamp column (hopefully). The check is done in basically the
exact same way the out-of-bounds check in timestamp2tm is done.
There's pro
18 matches
Mail list logo
