Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
...I did notice one final ...
Just checked in a fix to that one; and updated my website at
http://0ape.com/postgres_interval_patches/
and pushed it to my (hopefully fixed now) git server.
Applied with some revisions: I
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Rather than forcing Postgres mode; couldn't it put a
set intervalstyle = [whatever the current interval style is]
in the dump file?
This would work for loading into a PG = 8.4 server, and fail miserably
for loading into pre-8.4 servers.
Ron Mayer [EMAIL PROTECTED] writes:
So the options seem to be:
(1) Don't output a SQL-standard interval literal for the
value negative one days and negative one hours; perhaps
by sticking an extra '+' sign in there?
This is pretty much what the postgres style does...
(2) Force
BTW, I just noticed that CVS HEAD has a bug in reading negative SQL-spec
literals:
regression=# select interval '-2008-10';
interval
--
-2008 years -10 mons
(1 row)
regression=# select interval '--10';
interval
--
10 mons
(1 row)
Surely
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
(3) Put something into the dump file that will make the old
server reject the file rather than successfully loading
wrong data? (Some if intervalstyle==std and version8.3
abort loading the restore logic?)
There isn't any
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
There isn't any way to do that, unless you have a time machine in
your hip pocket. The trouble with putting
set intervalstyle = something;
into the dump script is that older servers will (by default) report
an error on that line and keep
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
The trouble is that older servers will (by default) report
an error on that line and keep right on chugging.
Not necessarily. Couldn't we put
select * from (select substring(version() from '[0-9\.]+') as version) as a
Ron Mayer [EMAIL PROTECTED] writes:
select * from (select substring(version() from '[0-9\.]+') as version) as a
join (select generate_series(0,1000)) as b on(version'8.4');
set intervalstyle = something;
[ shrug... ] It's still just one easily missable bleat.
Not here.
On my
Tom Lane wrote:
Oh, I see what you're trying to do. The answer is no. We're not going
to totally destroy back-portability of dumps, especially not for a
problem that won't even affect most people (negative intervals are
hardly common).
Similarly I wonder if pg_dump should add a fail if
Tom Lane wrote:
BTW, I just noticed that CVS HEAD has a bug in reading negative SQL-spec
literals:
regression=# select interval '-2008-10';
regression=# select interval '--10';
Surely the latter must mean -10 months. This is orthogonal to the
current patch ...
Perhaps the below
Another thought here ... I'm looking at the sign hack
+ if (IntervalStyle == INTSTYLE_SQL_STANDARD
+ field[0][0] == '-' i == 1
+ field[i][0] != '-' field[i][0] != '+')
+ {
+ /*--
+
Tom Lane wrote:
Another thought here ... I'm looking at the sign hack
+ if (IntervalStyle == INTSTYLE_SQL_STANDARD
and not liking it very much. Yes, it does the intended thing for strict
SQL-spec input, but it seems to produce a bunch of weird corner cases
for non-spec
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, I just noticed that CVS HEAD has a bug in reading negative SQL-spec
literals:
Perhaps the below patch fixes that?
Actually I think it should be
if (*field[i] == '-')
as in the comparable case for fractional seconds
Ron Mayer [EMAIL PROTECTED] writes:
Yes, at first glance I think that approach is better; but we'd need
to make sure not to apply the rule too enthusiastically on traditional
postgres intervals;
Well, of course we'd only apply it in SQL_STANDARD mode. The idea here
is that intervalstyle helps
I wrote:
... Consider
-1 1:00:00 flips the sign
- 1 1:00:00 doesn't flip the sign
-1 day 1:00:00 doesn't flip the sign
-2008-10 1:00:00flips the sign
-2008-10 1 doesn't flip the sign
-2008 years
: Brendan Jurd; Kevin Grittner; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for SQL-Standard Interval output and
decoupling DateStyle from IntervalStyle
BTW, I just noticed that CVS HEAD has a bug in reading negative SQL-
spec
literals:
regression=# select interval '-2008-10
Chuck McDevitt [EMAIL PROTECTED] writes:
Doesn't ANSI standard interval syntax have the minus sign before the quotes?
Select interval -'2008-10';
They allow it either there or inside the quotes.
We can't support outside-the-quotes unless we make INTERVAL a fully
reserved word (and even then
Ron Mayer [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
The changes to the documentation all look good. I did notice one
final typo that I think was introduced in the latest version.
doc/src/sgml/datatype.sgml:2270 has Nonstandardrd instead of
Nonstandard.
Just checked in a fix to that
Ron Mayer [EMAIL PROTECTED] writes:
Brendan Jurd wrote:
The changes to the documentation all look good. I did notice one
final typo that I think was introduced in the latest version.
doc/src/sgml/datatype.sgml:2270 has Nonstandardrd instead of
Nonstandard.
Just checked in a fix to that
Tom Lane wrote:
I've started reviewing this patch for commit, and I find myself a bit
disturbed by its compatibility properties. The SQL_STANDARD output
style is simply ambiguous: what is meant by
-1 1:00:00
? What you get from that will depend on the intervalstyle setting at
the
Ron Mayer wrote:
Tom Lane wrote:
*pg_dump had better force Postgres mode*. We can certainly do that with
a couple more lines added to the patch, but it's a bit troublesome that
we are boxed into using a nonstandard dump-data format until forever.
Ok. I see that is the concern..
Rather than
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've started reviewing this patch for commit, and I find myself a bit
disturbed by its compatibility properties. The SQL_STANDARD output
style is simply ambiguous: what is meant by
-1 1:00:00
? What you get from that will depend on the
Ron Mayer [EMAIL PROTECTED] writes:
Rather than forcing Postgres mode; couldn't it put a
set intervalstyle = [whatever the current interval style is]
in the dump file?
This would work for loading into a PG = 8.4 server, and fail miserably
for loading into pre-8.4 servers. Even though we don't
Tom Lane wrote:
ISO date format is read the same regardless of recipient's datestyle,
so pg_dump solves this by forcing the dump to be made in ISO style.
The corresponding solution for intervals will be to dump in POSTGRES
style, not SQL_STANDARD style, which seems a bit unfortunate.
[reading
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Rather than forcing Postgres mode; couldn't it put a
set intervalstyle = [whatever the current interval style is]
in the dump file?
This would work for loading into a PG = 8.4 server, and fail miserably
for loading into pre-8.4 servers.
Brendan Jurd wrote:
On Wed, Nov 5, 2008 at 7:34 AM, Ron Mayer [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
...new interval
Review of the other two patches coming soon to a mail client near you.
Oh - and for review of the next patch, ISO 8601's spec would no doubt
be useful.
I think this
I think we need to distinguish between patches that are clearly not
going in, and patches that are not going in in their present form but
might be able to be reworked. My suggestion would be that only the
first category be moved to the Returned with feedback section, and the
others just have
Brendan Jurd wrote:
...Sep 18, 2008... Ron Mayer [EMAIL PROTECTED] wrote:
The attached patch
(1) adds a new GUC called IntervalStyle that decouples interval
output from the DateStyle GUC, and
(2) adds a new interval style that will match the SQL standards
for interval
Ah. And one final question regarding functionality.
It seems to me that the last remaining place where we input
a SQL-2008 standard literal and do something different from
what the standard suggests is with the string:
'-1 2:03:04'
The standard seems to say that the - affects both the
days
Ron Mayer [EMAIL PROTECTED] writes:
Ah. And one final question regarding functionality.
It seems to me that the last remaining place where we input
a SQL-2008 standard literal and do something different from
what the standard suggests is with the string:
'-1 2:03:04'
The standard seems
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Ah. And one final question regarding functionality.
It seems to me that the last remaining place where we input
a SQL-2008 standard literal and do something different from
what the standard suggests is with the string:
'-1 2:03:04'
The
Brendan Jurd wrote:
...Sep 18, 2008...Ron Mayer [EMAIL PROTECTED] wrote:
(1) ...GUC called IntervalStyle...
(2) ...interval style that will match the SQL standards...
...an initial review...
When I ran the regression tests, I got one failure in the new interval
Fixed, and I did a
On Wed, Nov 5, 2008 at 7:34 AM, Ron Mayer [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
When I ran the regression tests, I got one failure in the new interval
Fixed, and I did a bit more testing both with and without
HAVE_INT64_TIMESTAMP.
Confirmed, all regression tests now pass on my system
Brendan Jurd wrote:
The changes to the documentation all look good. I did notice one
final typo that I think was introduced in the latest version.
doc/src/sgml/datatype.sgml:2270 has Nonstandardrd instead of
Nonstandard.
Just checked in a fix to that one; and updated my website at
On Thu, Sep 18, 2008 at 6:03 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
The attached patch
(1) adds a new GUC called IntervalStyle that decouples interval
output from the DateStyle GUC, and
(2) adds a new interval style that will match the SQL standards
for interval
Tom Lane wrote:
In fact, given that we are now
somewhat SQL-compliant on interval input, a GUC that selected
PG traditional, SQL-standard, or ISO 8601 interval output format seems
like it could be a good idea.
Short summary:
The attached patch
(1) adds a new GUC called IntervalStyle
36 matches
Mail list logo
