pgsql: Make operator precedence follow the SQL standard more closely.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Make operator precedence follow the SQL standard more closely.
Дата
Msg-id E1YVkLS-0005vm-KJ@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Make operator precedence follow the SQL standard more closely.

While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).

We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence.  And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.

Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.

Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.

The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes.  These warnings are off by default
and are enabled by the new GUC operator_precedence_warning.  It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/c6b3c939b7e0f1d35f4ed4996e71420a993810d2

Modified Files
--------------
doc/src/sgml/config.sgml                      |   23 ++
doc/src/sgml/syntax.sgml                      |   84 +++--
src/backend/nodes/outfuncs.c                  |    3 +
src/backend/parser/gram.y                     |   97 +++--
src/backend/parser/parse_expr.c               |  476 ++++++++++++++++++++++++-
src/backend/parser/parse_target.c             |    7 +-
src/backend/parser/parser.c                   |   17 +
src/backend/parser/scan.l                     |   33 +-
src/backend/utils/misc/guc.c                  |   10 +
src/backend/utils/misc/postgresql.conf.sample |    1 +
src/bin/psql/psqlscan.l                       |   21 ++
src/include/nodes/parsenodes.h                |    3 +-
src/include/parser/parse_expr.h               |    1 +
src/include/parser/scanner.h                  |    1 +
src/interfaces/ecpg/preproc/parse.pl          |    7 +-
src/interfaces/ecpg/preproc/parser.c          |   17 +
src/interfaces/ecpg/preproc/pgc.l             |   16 +-
src/pl/plpgsql/src/pl_gram.y                  |    1 +
18 files changed, 723 insertions(+), 95 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Allocate ParamListInfo once per plpgsql function, not once per e
Следующее
От: Robert Haas
Дата:
Сообщение: pgsql: Require non-NULL pstate for all addRangeTableEntryFor* functions