Thread: binary operators on integers
Here is my next take on binary operators for integers. It implements the following operators for int2/int4/int8: ~ - not & - and ^ - xor | - or << - shift left >> - shift right Notes: * My original choice for xor was '#' because the '^' operator conflicts with power operator on floats but Tom Lane said: > Well, you *could* use '^' since there's no definition of it for integer > operands. But that would mean that something like '4^2', which was > formerly implicitly coerced to float and interpreted as floating > power function, would suddenly mean something different. Again a > serious risk of silently breaking applications. This doesn't apply to > '|' though, since it has no numeric interpretation at all right now. As the bit-string uses '^' too for xor-ing it would be nice to be consistent. I am quite unsure on this matter. The patch now seems otherwise sane to me, this is the only issue left. * On << and >> the second argument is always int32 as this seems to be the 'default' int type in PostgreSQL. * Oids used are 1874 - 1909. Comments? Patch is against current CVS. -- marko
Attachment
Can someone comment on this? > Here is my next take on binary operators for integers. > It implements the following operators for int2/int4/int8: > > ~ - not > & - and > ^ - xor > | - or > << - shift left > >> - shift right > > Notes: > > * My original choice for xor was '#' because the '^' operator conflicts > with power operator on floats but Tom Lane said: > > > Well, you *could* use '^' since there's no definition of it for integer > > operands. But that would mean that something like '4^2', which was > > formerly implicitly coerced to float and interpreted as floating > > power function, would suddenly mean something different. Again a > > serious risk of silently breaking applications. This doesn't apply to > > '|' though, since it has no numeric interpretation at all right now. > > As the bit-string uses '^' too for xor-ing it would be nice to be > consistent. I am quite unsure on this matter. The patch now seems > otherwise sane to me, this is the only issue left. > > * On << and >> the second argument is always int32 as this seems > to be the 'default' int type in PostgreSQL. > > * Oids used are 1874 - 1909. > > Comments? > > Patch is against current CVS. > > -- > marko > [ 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?
We were debating what to do about the precedence issues; see
followup messages. I have no problem with adding functions
like this, just gotta pick the operator names and precedences...
regards, tom lane
This patch was installed, with xor as "#". The parser still needs work. Besides the known issue of "|", this also parses funny: => select 5 & ~ 6; ERROR: Unable to identify a right operator '&' for type 'int4' Marko Kreen writes: > Here is my next take on binary operators for integers. > It implements the following operators for int2/int4/int8: > > ~ - not > & - and > ^ - xor > | - or > << - shift left > >> - shift right > > Notes: > > * My original choice for xor was '#' because the '^' operator conflicts > with power operator on floats but Tom Lane said: > > > Well, you *could* use '^' since there's no definition of it for integer > > operands. But that would mean that something like '4^2', which was > > formerly implicitly coerced to float and interpreted as floating > > power function, would suddenly mean something different. Again a > > serious risk of silently breaking applications. This doesn't apply to > > '|' though, since it has no numeric interpretation at all right now. > > As the bit-string uses '^' too for xor-ing it would be nice to be > consistent. I am quite unsure on this matter. The patch now seems > otherwise sane to me, this is the only issue left. > > * On << and >> the second argument is always int32 as this seems > to be the 'default' int type in PostgreSQL. > > * Oids used are 1874 - 1909. > > Comments? > > Patch is against current CVS. > > -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Tue, Oct 24, 2000 at 10:23:55PM +0200, Peter Eisentraut wrote: > This patch was installed, with xor as "#". The parser still needs work. > Besides the known issue of "|", this also parses funny: > > => select 5 & ~ 6; > ERROR: Unable to identify a right operator '&' for type 'int4' I have known that from the beginning. On first patch I did not get it work correctly, so in second patch I disabled all gram.y hack altogether. So this patch does not change anything in parser/. At the moment it should be used: select 5 & (~ 6); I can hack the gram.y and scan.l to get those operators to work but as I saw no consensus has been reached in -hackers whether and how it should be solved globally? -- marko
Looks like this is fixed:
test=> select 5 & ~ 6;
ERROR: Unable to identify a right operator '&' for type 'int4'
You may need to add parentheses or an explicit cast
test=> select 5 & (~ 6);
?column?
----------
1
(1 row)
> This patch was installed, with xor as "#". The parser still needs work.
> Besides the known issue of "|", this also parses funny:
>
> => select 5 & ~ 6;
> ERROR: Unable to identify a right operator '&' for type 'int4'
>
>
> Marko Kreen writes:
>
> > Here is my next take on binary operators for integers.
> > It implements the following operators for int2/int4/int8:
> >
> > ~ - not
> > & - and
> > ^ - xor
> > | - or
> > << - shift left
> > >> - shift right
> >
> > Notes:
> >
> > * My original choice for xor was '#' because the '^' operator conflicts
> > with power operator on floats but Tom Lane said:
> >
> > > Well, you *could* use '^' since there's no definition of it for integer
> > > operands. But that would mean that something like '4^2', which was
> > > formerly implicitly coerced to float and interpreted as floating
> > > power function, would suddenly mean something different. Again a
> > > serious risk of silently breaking applications. This doesn't apply to
> > > '|' though, since it has no numeric interpretation at all right now.
> >
> > As the bit-string uses '^' too for xor-ing it would be nice to be
> > consistent. I am quite unsure on this matter. The patch now seems
> > otherwise sane to me, this is the only issue left.
> >
> > * On << and >> the second argument is always int32 as this seems
> > to be the 'default' int type in PostgreSQL.
> >
> > * Oids used are 1874 - 1909.
> >
> > Comments?
> >
> > Patch is against current CVS.
> >
> >
>
> --
> Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
>
>
--
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
On Fri, Jan 19, 2001 at 04:30:09PM -0500, Bruce Momjian wrote:
> Looks like this is fixed:
>
> test=> select 5 & ~ 6;
> ERROR: Unable to identify a right operator '&' for type 'int4'
> You may need to add parentheses or an explicit cast
> test=> select 5 & (~ 6);
> ?column?
> ----------
> 1
> (1 row)
I can still reproduce it:
marko=# SELECT 5 & ~6;
ERROR: Unable to identify a right operator '&' for type 'int4'
You may need to add parentheses or an explicit cast
Or did you mean it can be fixed with parenthesis? That was the
case from the beginning.
>
> > This patch was installed, with xor as "#". The parser still needs work.
> > Besides the known issue of "|", this also parses funny:
> >
> > => select 5 & ~ 6;
> > ERROR: Unable to identify a right operator '&' for type 'int4'
> >
--
marko
Marko Kreen <marko@l-t.ee> writes:
> I can still reproduce it:
> marko=# SELECT 5 & ~6;
> ERROR: Unable to identify a right operator '&' for type 'int4'
> You may need to add parentheses or an explicit cast
Correct, we did not rejigger the operator precedence.
I played around with this a little bit, and find that the attached patch
makes the above case work as desired --- essentially, it changes things
so that
a_expr Op Op a_expr
will be parsed as
a_expr Op (Op a_expr)
not
(a_expr Op) Op a_expr
which is what you get now because Op is marked left-associative.
Now, this is a situation where we can't fix one case without breaking
another, namely the case where you really DID want the first Op to be
parsed as a postfix operator. Thus the problem moves over to here:
regression=# select 4! ~ 10;
ERROR: Unable to identify an operator '!' for types 'int4' and 'int4'
You will have to retype this query using an explicit cast
regression=# select (4!) ~ 10;
?column?
----------
f
(1 row)
whereas this worked without parens in 7.0.
Given the infrequency of use of postfix operators compared to prefix,
I am inclined to think that we should change the grammar to make the
latter easier to use at the expense of the former. On the other hand,
it seems there's a pretty large risk of backwards-incompatibility here.
Comments?
BTW, the regress tests do not break, so they contain no examples where
it makes a difference.
regards, tom lane
*** src/backend/parser/gram.y.orig Sat Jan 20 12:37:52 2001
--- src/backend/parser/gram.y Sat Jan 20 13:03:17 2001
***************
*** 383,388 ****
--- 383,389 ----
%nonassoc OVERLAPS
%nonassoc BETWEEN
%nonassoc IN
+ %left POSTFIXOP /* dummy for postfix Op rules */
%left Op /* multi-character ops and user-defined operators */
%nonassoc NOTNULL
%nonassoc ISNULL
***************
*** 4312,4320 ****
{ $$ = makeA_Expr(OP, "+", NULL, $2); }
| '-' a_expr %prec UMINUS
{ $$ = doNegate($2); }
! | '%' a_expr
{ $$ = makeA_Expr(OP, "%", NULL, $2); }
! | '^' a_expr
{ $$ = makeA_Expr(OP, "^", NULL, $2); }
| a_expr '%'
{ $$ = makeA_Expr(OP, "%", $1, NULL); }
--- 4313,4321 ----
{ $$ = makeA_Expr(OP, "+", NULL, $2); }
| '-' a_expr %prec UMINUS
{ $$ = doNegate($2); }
! | '%' a_expr %prec UMINUS
{ $$ = makeA_Expr(OP, "%", NULL, $2); }
! | '^' a_expr %prec UMINUS
{ $$ = makeA_Expr(OP, "^", NULL, $2); }
| a_expr '%'
{ $$ = makeA_Expr(OP, "%", $1, NULL); }
***************
*** 4353,4361 ****
| a_expr Op a_expr
{ $$ = makeA_Expr(OP, $2, $1, $3); }
! | Op a_expr
{ $$ = makeA_Expr(OP, $1, NULL, $2); }
! | a_expr Op
{ $$ = makeA_Expr(OP, $2, $1, NULL); }
| a_expr AND a_expr
--- 4354,4362 ----
| a_expr Op a_expr
{ $$ = makeA_Expr(OP, $2, $1, $3); }
! | Op a_expr %prec UMINUS
{ $$ = makeA_Expr(OP, $1, NULL, $2); }
! | a_expr Op %prec POSTFIXOP
{ $$ = makeA_Expr(OP, $2, $1, NULL); }
| a_expr AND a_expr
***************
*** 4560,4568 ****
{ $$ = makeA_Expr(OP, "+", NULL, $2); }
| '-' b_expr %prec UMINUS
{ $$ = doNegate($2); }
! | '%' b_expr
{ $$ = makeA_Expr(OP, "%", NULL, $2); }
! | '^' b_expr
{ $$ = makeA_Expr(OP, "^", NULL, $2); }
| b_expr '%'
{ $$ = makeA_Expr(OP, "%", $1, NULL); }
--- 4561,4569 ----
{ $$ = makeA_Expr(OP, "+", NULL, $2); }
| '-' b_expr %prec UMINUS
{ $$ = doNegate($2); }
! | '%' b_expr %prec UMINUS
{ $$ = makeA_Expr(OP, "%", NULL, $2); }
! | '^' b_expr %prec UMINUS
{ $$ = makeA_Expr(OP, "^", NULL, $2); }
| b_expr '%'
{ $$ = makeA_Expr(OP, "%", $1, NULL); }
***************
*** 4589,4597 ****
| b_expr Op b_expr
{ $$ = makeA_Expr(OP, $2, $1, $3); }
! | Op b_expr
{ $$ = makeA_Expr(OP, $1, NULL, $2); }
! | b_expr Op
{ $$ = makeA_Expr(OP, $2, $1, NULL); }
;
--- 4590,4598 ----
| b_expr Op b_expr
{ $$ = makeA_Expr(OP, $2, $1, $3); }
! | Op b_expr %prec UMINUS
{ $$ = makeA_Expr(OP, $1, NULL, $2); }
! | b_expr Op %prec POSTFIXOP
{ $$ = makeA_Expr(OP, $2, $1, NULL); }
;
On Sat, Jan 20, 2001 at 01:31:49PM -0500, Tom Lane wrote: > Given the infrequency of use of postfix operators compared to prefix, > I am inclined to think that we should change the grammar to make the > latter easier to use at the expense of the former. On the other hand, > it seems there's a pretty large risk of backwards-incompatibility here. > Comments? I say, go for it! :) if it matters anything :] And the backwards incompatibility should be simply mentioned in release notes. Only problem is, that this is such a obscure incompatibility that I am not sure e.g. distro packagers bother to mention it in new 7.1 install splash-screens. "If you have used factorial '!' or start of interval '|' operator in expressions, note that ..." ? -- marko
I wrote:
> Given the infrequency of use of postfix operators compared to prefix,
> I am inclined to think that we should change the grammar to make the
> latter easier to use at the expense of the former. On the other hand,
> it seems there's a pretty large risk of backwards-incompatibility here.
> Comments?
I backed away from part of the proposed patch --- changing the
precedence of all the prefix-operator productions to UMINUS would
probably break people's queries. But I've applied the part that
changes the behavior of a_expr Op Op a_expr. This will now be
parsed as an infix operator followed by a prefix operator.
regards, tom lane