From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Roy Badami <roy(at)gnomon(dot)org(dot)uk> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1517: SQL interval syntax is accepted by the parser, |
Date: | 2005-03-19 21:03:22 |
Message-ID: | 18273.1111266202@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Roy Badami <roy(at)gnomon(dot)org(dot)uk> writes:
> Similary the undocumented postgresism of interpreting
> INTERVAL '1:02'
> as 1 hour 2 minutes is consistent with the ANSI
> INTERVAL '1:02' HOUR TO MINUTE
> but not with the ANSI
> INTERVAL '1:02' MINUTE TO SECOND
> which of course means 1 minute 2 seconds.
Well, that's an annoying case but I don't think it means we should throw
up our hands and reject cases that are (a) perfectly unambiguous and
(b) accepted by the present and past code.
We have to be able to support casts from undecorated INTERVAL to
INTERVALs with typmods, so most of these issues *have* to be dealt with
anyway; we can't arbitrarily reject them. What I am thinking is that
(a) if the input string is undecorated or ambiguous, use the typmod
to help resolve it --- in particular this should cover all of the
spec-mandated cases.
(b) if it is unambiguous Postgres-style syntax, read it that way and
then perform a cast to the restricted interval type.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David B. | 2005-03-20 06:21:54 | pl/pgsql doesn't load |
Previous Message | Roy Badami | 2005-03-19 20:46:43 | Re: BUG #1517: SQL interval syntax is accepted by the parser, |