On Mon, 8 Sep 2003 00:51:45 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
>This has been saved for the 7.5 release:
>
> http:/momjian.postgresql.org/cgi-bin/pgpatches2
Here is the combined patch. Prior patches in this thread are hereby
obsolete.
Servus
Manfred
diff -ruN ../base/
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Larry Rosenman wrote:
Here's a quickie patch I did to fix it.
Patching this or not, if the function's called the backend will SEGV
either (at least on my 2.4.20 it does) because a IPV6 address is copied
in the memory sp
Thanks Tom,
I just cvs update'd and it ccompiles and regression tests pass.
I've have no time today to go further though
On Sun, 7 Sep 2003, Tom Lane wrote:
> Date: Sun, 07 Sep 2003 20:57:04 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Andreas Pflug <[EMAIL PROTECTED]>
> Cc: Larry Rosenman <[
I've added parsing of the V3 protocol's notice and error messages into its
various fields. This replaces the current error message format of:
SERRORC42P01Mrelation "this_table_doesnt_exist" does not
existFnamespace.cL193RRangeVarGetRelid
with the correct message and allows the programmer to ret
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > A test for null string is missing here:
>
> > MemoryContextStrdup(MemoryContext context, const char *string)
> > {
> > char *nstr;
> > -
> > - if ( !string )
> > - {
> > - elog(ERROR, "MemoryContextStrdup cal
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This has been saved for the 7.5 release:
> > http:/momjian.postgresql.org/cgi-bin/pgpatches2
>
> BTW, that page still calls itself "PostgreSQL Items For 7.4."
Thanks. Fixed.
--
Bruce Momjian| http://
This has been saved for the 7.5 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Manfred Koizar wrote:
> On Mon, 8 Sep 2003 00:51:45 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >
> >This ha
Manfred, can I get a description for this patch? Thanks.
---
Manfred Koizar wrote:
> On Mon, 8 Sep 2003 00:51:45 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >
> >This has been saved for the 7.5 release:
> >
>
Tom wrote:
> "Ron Mayer" <[EMAIL PROTECTED]> writes:
> >Compared to the ISO 8601 time interval specification, the
> >postgresql interval syntax is quite verbose. For example:
>
> > Postgresql interval: ISO8601 Interval
> > --
[EMAIL PROTECTED] wrote:
>
> Is there a way of producing as well as reading this format? Or did I miss
> something?
Not yet, but I'd be happy to add it.
My immediate problem was having some 'P1Y6M' intervals to load.
I posted this much largely because it was useful to me so might
help others
"Ron Mayer" <[EMAIL PROTECTED]> writes:
> Tom wrote:
>> Er, don't we support that already?
> Postgresql supports a rather bizzare shorthand that has a similar
> syntax, but AFAICT, doesn't match ISO 8601 in any way that makes
> it practical.
Well, it's *supposed* to match ISO, AFAICT (the commen
"Ron Mayer" <[EMAIL PROTECTED]> writes:
> Would it be useful if I added a 'datestyle' of 'ISO basic' which
> would produce the most terse formats ('19980115' for dates,
> and 'P1Y1M' for intervals)?
I don't really care for using that name for it --- for one thing, you
couldn't do
set date
This has been saved for the 7.5 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
Feel free to submit an updated patch that rips out the old syntax, as
discussed, or replace this patch with a more comprehensive one.
Tom Lane wrote:
> > Perhaps one could argue that the postgres shorthand should
> > follow the ISO conventions, but I'd not want to break backward
> > compatability, incase someone out there is using '1H30M' and
> > expecting minutes instead of months.
>
> I doubt anyone is using it, because it's
Tom wrote:
> "Ron Mayer" <[EMAIL PROTECTED]> writes:
> > Tom wrote:
> >> Er, don't we support that already?
> > ...AFAICT, doesn't match ISO 8601...
>
> Well, it's *supposed* to match ISO Unless ISO has put out
> multiple specs that cover this?
Any way to tell if this is the case.
8601's
Ron Mayer wrote:
> If I'm breaking backward compatability anyway, I'd be happy to tweak
> things like this one too. Unless, of course someone can give me a
> reason why we want fractional years rounded to months, but fractional
> months are rounded to fractions of a second.
>
>Ron Mayer.
>
"Neil Conway" <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-09-08 at 11:09, Gaetano Mendola wrote:
> > "Tom Lane" <[EMAIL PROTECTED]> wrote:
> > > I see no value at all in an assert. The code will dump core just fine
> > > with or without an assert ...
> >
> > Right but an assert can display informati
"Ron Mayer" <[EMAIL PROTECTED]> writes:
> For example "why is 0.001 years less than 0.001 months".
And look at this:
regression=# select '0.99 years'::interval;
interval
--
11 mons
(1 row)
regression=# select '0.99 months'::interval;
interval
--
29 days 16:48:00
Tom Lane writes:
> "Ron Mayer" <[EMAIL PROTECTED]> writes:
> > Would it be useful if I added a 'datestyle' of 'ISO basic' which
> > would produce the most terse formats ('19980115' for dates,
> > and 'P1Y1M' for intervals)?
>
> I don't really care for using that name for it --- for one thing, you
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I don't really care for using that name for it ---
> iso8601
> Keep in mind that SQL itself is also a kind of ISO, so being more specific
> is useful.
Yes, but by the same token "iso8601" isn't specific enough either.
Several of
Tom Lane writes:
> Yes, but by the same token "iso8601" isn't specific enough either.
> Several of the other input formats we support have at least as good a
> claim on that name.
The only input formats we support are along the lines of
@ 1 year 2 mons 3 days 4 hours 5 mins 6 secs
@ 1 year 2 mon
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Yes, but by the same token "iso8601" isn't specific enough either.
>> Several of the other input formats we support have at least as good a
>> claim on that name.
> The only input formats we support are along the lines of
> @ 1 ye
Tom wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> Yes, but by the same token "iso8601" isn't specific enough either.
ISO 8601 gives more specific names.
ISO 8601 Basic Format: P2Y10M15DT10H20M30S
ISO 8601 Alternative Format: P00021015T102030
ISO
[ backtracking a little ]
"Ron Mayer" <[EMAIL PROTECTED]> writes:
> Tom wrote:
>> I doubt anyone is using it, because it's completely undocumented.
>> If we're going to support the real ISO spec, I'd suggest ripping
>> out any not-quite-there variant.
> I'm happy to look into it. Rip out comple
On Mon, 2003-09-08 at 11:09, Gaetano Mendola wrote:
> "Tom Lane" <[EMAIL PROTECTED]> wrote:
> > I see no value at all in an assert. The code will dump core just fine
> > with or without an assert ...
>
> Right but an assert can display information about the file and line number
> without debug t
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Gaetano Mendola" <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> wrote:
> >> This seems inappropriate to me. Are you going to suggest that every
> >> routine that takes a pointer parameter needs to explicitly test for
> >> null?
>
> > Of cou
> > I don't think so, because the patch does nothing to keep the sort
> > order once the index is initially created.
>
> As Tom mentioned, we might not want to keep the tid's in order after the
> index is created because he wants the most recent tid's first, so the
> expired ones migrate to the e
On Mon, 8 Sep 2003 11:31:05 +0200, "Zeugswetter Andreas SB SD"
<[EMAIL PROTECTED]> wrote:
>> As Tom mentioned, we might not want to keep the tid's in order after the
>> index is created because he wants the most recent tid's first, so the
>> expired ones migrate to the end.
>
>But on average this a
28 matches
Mail list logo
