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 fro
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 suppl
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?
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 day-h
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:
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
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
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_860
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
GU
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:
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 ze
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" o
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
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 both
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
reje
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
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:
> 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
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:
> 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 tha
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 is different?
The patch seems to support extensions to the standard.
Right. All of t
(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.)
Not
"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 is different?
> The patch seems to support extensions to the standard.
Right. All of these were e
>>> 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 is different?
The patch seems to support extensions to the standard
24 matches
Mail list logo