Skip site navigation (1) Skip section navigation (2)

Re: Interval constant syntax, was Re: Interval & check clause

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: "Karl O(dot) Pinc" <kop(at)meme(dot)com>,Bruno BAGUETTE <pgsql-ml(at)baguette(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Interval constant syntax, was Re: Interval & check clause
Date: 2004-03-30 05:42:28
Message-ID: 27508.1080625348@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> This is different in that you are using - instead of >= . Date - Date
> will get picked because that is the only - operator with a left operand
> of type date.

Even if it weren't the only one, there is a preferential case involved:
given "known_type operator unknown_literal", the parser will
preferentially assume that the unknown_literal is the same type as the
other operand, if there is an available operator that takes that type
on both sides.  For details see
	http://www.postgresql.org/docs/7.4/static/typeconv-oper.html
(rule 2a is my point here).

Note that in *no* case will the contents of the string literal have any
a-priori effect on the parser's decision about what the literal's type
is.  I believe this is a good policy in general --- doing otherwise
would render the behavior way too unpredictable, since often the
contents of the literal are not under the control of the SQL query
author.  But this does mean that just writing '2 days' is not going
to be enough to make the system think it is an interval constant.
There must be some cue to the type outside the quotes, whether an
explicit cast or an implicit match to another operand.

			regards, tom lane

In response to

pgsql-general by date

Next:From: Bruno BaguetteDate: 2004-03-30 07:40:02
Subject: Best open source db poll currently
Previous:From: Bruno Wolff IIIDate: 2004-03-30 05:22:36
Subject: Re: Interval constant syntax, was Re: Interval & check clause

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group