| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kris Jurka <books(at)ejurka(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: AT TIME ZONE INTERVAL and prepared statements |
| Date: | 2004-10-22 23:02:07 |
| Message-ID: | 20003.1098486127@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Kris Jurka <books(at)ejurka(dot)com> writes:
> On Fri, 22 Oct 2004, Tom Lane wrote:
>> You are confusing the syntax for a typed literal with part of the AT
>> TIME ZONE construct.
> Could you explain what the difference is between a typed literal
> "int '11'" and a cast(ed) literal "'11'::int" to me they seem like the
> same thing.
Yes, they are semantically the same. The first one is a kluge that Tom
Lockhart put in to approximate the SQL spec's demands for representation
of timestamp and interval constants. It does not work syntactically to
try to extend it to a general cast construct (we can only barely manage
to support it as-is --- there are various special cases that don't work
such as arrays and qualified type names, and a depressingly large part
of gram.y is devoted to getting the cases that do work to work). Even
if we could get the parser to cope with that without reduce/reduce
errors, we'd be greatly reducing the grammar's ability to detect actual
syntax errors, because practically anything next to practically anything
else would become a potentially legal cast construct.
So, no "INTERVAL $1". Bad enough we have to take "INTERVAL 'string'".
This wasn't one of the SQL committee's better ideas.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-10-22 23:07:24 | Re: Problem with rule and null value |
| Previous Message | Kris Jurka | 2004-10-22 22:48:51 | Re: AT TIME ZONE INTERVAL and prepared statements |