pgsql: Add BETWEEN SYMMETRIC.
Log Message:
-----------
Add BETWEEN SYMMETRIC.
Pavel Stehule
Modified Files:
--------------
pgsql/doc/src/sgml:
func.sgml (r1.255 -> r1.256)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml.diff?r1=1.255&r2=1.256)
pgsql/src/backend/parser:
gram.y (r2.492 -> r2.493)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/gram.y.diff?r1=2.492&r2=2.493)
keywords.c (r1.155 -> r1.156)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/keywords.c.diff?r1=1.155&r2=1.156)
With this Bruce, is there any reason this was accepted now, and not
several years ago when I first submitted it? :D
Also, you can update our SQL99 compatibility list to indicate that we
now have this feature :)
Chris
Bruce Momjian wrote:
Show quoted text
Log Message:
-----------
Add BETWEEN SYMMETRIC.Pavel Stehule
Modified Files:
--------------
pgsql/doc/src/sgml:
func.sgml (r1.255 -> r1.256)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml.diff?r1=1.255&r2=1.256)
pgsql/src/backend/parser:
gram.y (r2.492 -> r2.493)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/gram.y.diff?r1=2.492&r2=2.493)
keywords.c (r1.155 -> r1.156)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/keywords.c.diff?r1=1.155&r2=1.156)---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Christopher Kings-Lynne wrote:
With this Bruce, is there any reason this was accepted now, and not
several years ago when I first submitted it? :D
Uh, I wasn't around then. (No, that isn't going to work.) Uh, no idea.
I think there is a sense now that doing BETWEEN in gram.y isn't so bad
because the optimizer can deal with the AND conditation better than
perhaps it could in the past, but that is total guess.
Also, you can update our SQL99 compatibility list to indicate that we
now have this feature :)
Done.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Christopher Kings-Lynne wrote:
With this Bruce, is there any reason this was accepted now, and not
several years ago when I first submitted it? :D
Uh, I wasn't around then. (No, that isn't going to work.) Uh, no idea.
I think there is a sense now that doing BETWEEN in gram.y isn't so bad
because the optimizer can deal with the AND conditation better than
perhaps it could in the past, but that is total guess.
No, that's exactly it: the original patch was rejected because it made
BETWEEN unoptimizable, IIRC. The change from then to now likely has
more to do with improvements in the optimizer than with the content of
the BETWEEN ASYMMETRIC patch itself.
We are still not totally done on this issue --- as Peter pointed out,
it'd be a lot nicer to represent "a BETWEEN b AND c" as a special
expression node that evaluates "a" only once. BETWEEN ASYMMETRIC is
worse because it may evaluate b and c multiple times too. The missing
part is to teach the optimizer to plan such a thing correctly ...
regards, tom lane
momjian@svr1.postgresql.org (Bruce Momjian) writes:
Add BETWEEN SYMMETRIC.
$ make
bison -y -d gram.y
conflicts: 4 shift/reduce
This is absolutely unacceptable.
regards, tom lane
