patch for BETWEEN [ASYMMETRIC|SYMMETRIC]
This was a trivial thing to implement in the parser (unless I overlooked
something!). Please review it and let me know if I missed something. This
adds SQL-1999 BETWEEN [ASYMMETRIC|SYMMETRIC] language. Hopefully it's not
considered just SQL bloat. ;)
--
-------- Robert B. Easter reaster@comptechnews.com ---------
-- CompTechNews Message Board http://www.comptechnews.com/ --
-- CompTechServ Tech Services http://www.comptechserv.com/ --
---------- http://www.comptechnews.com/~reaster/ ------------
"Robert B. Easter" <reaster@comptechnews.com> writes:
This was a trivial thing to implement in the parser (unless I overlooked
something!). Please review it and let me know if I missed something.
ColId (or at least ColLabel) entries for the added keywords.
This doesn't strike me as a particularly efficient implementation,
but until there's a groundswell of actual use, maybe we don't care...
regards, tom lane
This was a trivial thing to implement in the parser (unless I overlooked
something!). Please review it and let me know if I missed something. This
adds SQL-1999 BETWEEN [ASYMMETRIC|SYMMETRIC] language. Hopefully it's not
considered just SQL bloat. ;)
No more bloat than in the rest of the language ;)
I *assume* that this will have trouble making it in to 7.1, and since
keywords are likely added this may have trouble with 7.1.x (not sure
about that; perhaps the lex-generated token values never make it into
the database tables, but they *do* propagate into structures used deeper
in the backend).
- Thomas
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I *assume* that this will have trouble making it in to 7.1, and since
keywords are likely added this may have trouble with 7.1.x (not sure
about that; perhaps the lex-generated token values never make it into
the database tables, but they *do* propagate into structures used deeper
in the backend).
Since he didn't add a new parsetree node type, there wouldn't be any
database compatibility issue AFAIK. I'm pretty certain that keyword
token values never get into stored rules.
However, there is our self-imposed "no new features during beta" rule.
This looks like a relatively harmless patch, but do we want to break
that rule for something that people are not beating down our doors for?
I'd vote for holding it for 7.2, I think.
regards, tom lane
I concur. about holding for 7.2. Though this is of limited danger, it
is not something that is really in hight demand.
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I *assume* that this will have trouble making it in to 7.1, and since
keywords are likely added this may have trouble with 7.1.x (not sure
about that; perhaps the lex-generated token values never make it into
the database tables, but they *do* propagate into structures used deeper
in the backend).Since he didn't add a new parsetree node type, there wouldn't be any
database compatibility issue AFAIK. I'm pretty certain that keyword
token values never get into stored rules.However, there is our self-imposed "no new features during beta" rule.
This looks like a relatively harmless patch, but do we want to break
that rule for something that people are not beating down our doors for?I'd vote for holding it for 7.2, I think.
regards, tom lane
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Can someone comment on this?
[ Charset ISO-8859-1 unsupported, converting... ]
This was a trivial thing to implement in the parser (unless I overlooked
something!). Please review it and let me know if I missed something. This
adds SQL-1999 BETWEEN [ASYMMETRIC|SYMMETRIC] language. Hopefully it's not
considered just SQL bloat. ;)--
-------- Robert B. Easter reaster@comptechnews.com ---------
-- CompTechNews Message Board http://www.comptechnews.com/ --
-- CompTechServ Tech Services http://www.comptechserv.com/ --
---------- http://www.comptechnews.com/~reaster/ ------------
[ Attachment, skipping... ]
[ Attachment, skipping... ]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
Can someone comment on this?
It's a new feature, so it should wait for 7.2 ...
In any case, there are further considerations here, like getting
ruleutils.c to reverse-list the construct correctly. When we
redesign querytree structures, reconstructability needs to be one
of the considerations.
regards, tom lane
Robert, did we ever resolve if this is a valuable patch?
[ Charset ISO-8859-1 unsupported, converting... ]
This was a trivial thing to implement in the parser (unless I overlooked
something!). Please review it and let me know if I missed something. This
adds SQL-1999 BETWEEN [ASYMMETRIC|SYMMETRIC] language. Hopefully it's not
considered just SQL bloat. ;)--
-------- Robert B. Easter reaster@comptechnews.com ---------
-- CompTechNews Message Board http://www.comptechnews.com/ --
-- CompTechServ Tech Services http://www.comptechserv.com/ --
---------- http://www.comptechnews.com/~reaster/ ------------
[ Attachment, skipping... ]
[ Attachment, skipping... ]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Can someone comment on where we left this?
This was a trivial thing to implement in the parser (unless I overlooked
something!). Please review it and let me know if I missed something. This
adds SQL-1999 BETWEEN [ASYMMETRIC|SYMMETRIC] language. Hopefully it's not
considered just SQL bloat. ;)
---------------------------------------------------------------------------
*** gram.y Wed Jan 10 20:45:40 2001
--- gram.y.modi Wed Jan 10 20:44:38 2001
***************
*** 321,332 ****
WHEN, WHERE, WITH, WORK, YEAR_P, ZONE /* Keywords (in SQL3 reserved words) */
! %token CHAIN, CHARACTERISTICS,
DEFERRABLE, DEFERRED,
IMMEDIATE, INITIALLY, INOUT,
OFF, OUT,
PATH_P, PENDANT,
RESTRICT,
TRIGGER,
WITHOUT
--- 321,334 ----
WHEN, WHERE, WITH, WORK, YEAR_P, ZONE /* Keywords (in SQL3 reserved words) */
! %token ASYMMETRIC,
! CHAIN, CHARACTERISTICS,
DEFERRABLE, DEFERRED,
IMMEDIATE, INITIALLY, INOUT,
OFF, OUT,
PATH_P, PENDANT,
RESTRICT,
+ SYMMETRIC,
TRIGGER,
WITHOUT
***************
*** 4452,4462 ****
--- 4454,4496 ----
makeA_Expr(OP, ">=", $1, $3),
makeA_Expr(OP, "<=", $1, $5));
}
+ | a_expr BETWEEN ASYMMETRIC b_expr AND b_expr
+ {
+ $$ = makeA_Expr(AND, NULL,
+ makeA_Expr(OP, ">=", $1, $4),
+ makeA_Expr(OP, "<=", $1, $6));
+ }
+ | a_expr BETWEEN SYMMETRIC b_expr AND b_expr
+ {
+ $$ = makeA_Expr(OR, NULL,
+ makeA_Expr(AND, NULL,
+ makeA_Expr(OP, ">=", $1, $4),
+ makeA_Expr(OP, "<=", $1, $6)),
+ makeA_Expr(AND, NULL,
+ makeA_Expr(OP, ">=", $1, $6),
+ makeA_Expr(OP, "<=", $1, $4)) );
+ }
| a_expr NOT BETWEEN b_expr AND b_expr
{
$$ = makeA_Expr(OR, NULL,
makeA_Expr(OP, "<", $1, $4),
makeA_Expr(OP, ">", $1, $6));
+ }
+ | a_expr NOT BETWEEN ASYMMETRIC b_expr AND b_expr
+ {
+ $$ = makeA_Expr(OR, NULL,
+ makeA_Expr(OP, "<", $1, $5),
+ makeA_Expr(OP, ">", $1, $7));
+ }
+ | a_expr NOT BETWEEN SYMMETRIC b_expr AND b_expr
+ {
+ $$ = makeA_Expr(AND, NULL,
+ makeA_Expr(OR, NULL,
+ makeA_Expr(OP, "<", $1, $5),
+ makeA_Expr(OP, ">", $1, $7)),
+ makeA_Expr(OR, NULL,
+ makeA_Expr(OP, "<", $1, $7),
+ makeA_Expr(OP, ">", $1, $5)) );
}
| a_expr IN '(' in_expr ')'
{--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
Can someone comment on where we left this?
The grammar patch is incorrect/incomplete as given (no keywords.c
entries, no additions to the TokenId list), unless you quoted only
part of it.
More generally, I hate to see us yet again doing a quick shortcut that
loses information. BETWEEN really ought to be a 3-operand function or
special expression node type, so that it (a) can be reverse-listed
sensibly, and (b) doesn't result in multiple evaluations of its inputs.
regards, tom lane
OK, patch rejected.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Can someone comment on where we left this?
The grammar patch is incorrect/incomplete as given (no keywords.c
entries, no additions to the TokenId list), unless you quoted only
part of it.More generally, I hate to see us yet again doing a quick shortcut that
loses information. BETWEEN really ought to be a 3-operand function or
special expression node type, so that it (a) can be reverse-listed
sensibly, and (b) doesn't result in multiple evaluations of its inputs.regards, tom lane
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026