Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, which Interval TODO items did you complete with this patch?
http://wiki.postgresql.org/wiki/Todo#Dates_and_Times
I think we've at least mostly fixed
* Support ISO INTERVAL syntax if units cannot be determined from the
Tom Lane wrote:
There is still some unfinished business if anyone wants to make it
really exactly 100% spec compliant ...
I agree.
I committed the patch as presented, and I think I might go take a quick
Tom, which Interval TODO items did you complete with this patch?
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, which Interval TODO items did you complete with this patch?
http://wiki.postgresql.org/wiki/Todo#Dates_and_Times
I think we've at least mostly fixed
* Support ISO INTERVAL syntax if units cannot be determined from the string,
and are supplied
Tom Lane wrote:
support for SQL-spec interval literals. I decided to go look at exactly
how unfinished it was, and it turns out that it's actually pretty close.
Hence the attached proposed patch ;-)
Is this code handling negative interval literals right?
I think I quote the relevant spec part
Ron Mayer [EMAIL PROTECTED] writes:
Is this code handling negative interval literals right?
I think I quote the relevant spec part at the bottom.
We support independent signs for the different components of the
interval. I'm not sure how well the spec copes with that.
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Is this code handling negative interval literals right?
I think I quote the relevant spec part at the bottom.
We support independent signs for the different components of the
Even so it surprises me that:
'-1-1'::interval gives me a
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
interval ... sql_standard...iso_8601...
backward_compatible ...depends... on ... DateStyle...
...How about decoupling interval_out's behavior
from DateStyle altogether, and instead providing values of IntervalStyle
that match all the
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
... ISO 8601 intervals ...
On the output side, seems like a GUC variable
is the standard precedent here. I'd still vote against overloading
DateStyle --- it does too much already --- but a separate variable for
interval style wouldn't
Tom Lane wrote:
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.
Trying to do the SQL-standard output now, and have a question
of what to do in the SQL-standard mode when trying to
Ron Mayer [EMAIL PROTECTED] writes:
Trying to do the SQL-standard output now, and have a question
of what to do in the SQL-standard mode when trying to output
an interval that as both a YEAR and a DAY component.
AFAICT the SQL standard doesn't let you have both, so the
SQL-standard output
Tom Lane wrote:
The reason it's not SQL-standard is the data value isn't.
So not a problem. Someone conforming to the spec limits on
what he puts in will see spec-compliant output. I think all
you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if
zeroes, omit dd if zero, omit hh:mm:ss if
Ron Mayer wrote:
Tom Lane wrote:
you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if
zeroes, omit dd if zero, omit hh:mm:ss if zeroes (but maybe
only if dd is also 0? otherwise your output is just dd which
is uncomfortably ambiguous).
Oh, and if both parts are 0, I guess we desire
the
Tom Lane wrote:
I think all
you need is 'yyy-mm dd hh:mm:ss' where you omit yyy-mm if
zeroes, omit dd if zero, omit hh:mm:ss if zeroes (but maybe
only if dd is also 0? otherwise your output is just dd which
is uncomfortably ambiguous).
Cool. I think I have it pretty much working with a new
Ron Mayer [EMAIL PROTECTED] writes:
Cool. I think I have it pretty much working with a new
GUC intervalstyle that can take values of
sql_standard that I think will output SQL standard
interval literals when given a sql
standard interval.
iso_8601 that will
Tom Lane wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I am not sure about some of the corner cases --- anyone want to see if
their understanding of the spec for interval string is different?
The patch seems to support extensions to the standard.
Right.
Ron Mayer [EMAIL PROTECTED] writes:
Back a while ago (2003) there was some talk about replacing
some of the non-standard extensions with shorthand forms of
intervals with ISO 8601 intervals that have a similar but
not-the-same shorthand.
I think *replacement* would be a hard sell, as that
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Back a while ago (2003) there was some talk about replacing
some of the non-standard extensions with shorthand forms of
intervals with ISO 8601 intervals that have a similar but
not-the-same shorthand.
I think *replacement* would be a hard
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think *replacement* would be a hard sell, as that would tick off all
the existing users ;-). Now it seems like being able to accept either
I originally submitted a patch that supported both, and I think
you suggested replacing on the
Tom Lane wrote:
The other problem is that the SQL spec clearly defines an interval
literal syntax, and it's not this ISO thing. So even without backward
compatibility issues, 8601-only doesn't seem like it would fly.
Oh. I wasn't proposing 8601-only. Just the one-character
shorthands like
Ron Mayer [EMAIL PROTECTED] writes:
Oh. I wasn't proposing 8601-only. Just the one-character
shorthands like '1Y1M'::interval that postgresql interprets
as 1 year one minute. No standard specifies anything close
to that; and any similar standards ask to interpret that M as
months instead
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
'1Y1M'::interval ... minute ... month
Hmmm. I would say that the problem with that is not that it's
nonstandard but that it's ambiguous.
Ah yes.
Our documentation...says...or abbreviations.
...What if we just tweak the code to
reject
Tom Lane [EMAIL PROTECTED] wrote:
The patch includes regression test changes that illustrate what it
does.
I am not sure about some of the corner cases --- anyone want to see
if
their understanding of the spec for interval string is different?
The patch seems to support extensions to the
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I am not sure about some of the corner cases --- anyone want to see if
their understanding of the spec for interval string is different?
The patch seems to support extensions to the standard.
Right. All of these
(1) In the spec, an interval value or literal must be either
year-month or day-time. (I guess they didn't want to try to deal with
the sticky issues of what it means to have an interval of, for
example, seven months and three days -- since an interval has no sense
of which seven months.)
24 matches
Mail list logo
