Thread: 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/ ------------
Attachment
"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 19026
Can 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 19026
Bruce 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 19026
Can 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 19026
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
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