OSDN Git Service

Ensure that typmod decoration on a datatype name is validated in all cases,
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 11 Nov 2007 19:22:49 +0000 (19:22 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 11 Nov 2007 19:22:49 +0000 (19:22 +0000)
commit0bd4da23a4bee4fb3b6b61cb0fadc43c054c5ddb
tree2a37c084e71feafe8e502758e7e01446192d9529
parent6b8cc88268fcf33b5e2d3c230f097dff0541398f
Ensure that typmod decoration on a datatype name is validated in all cases,
even in code paths where we don't pay any subsequent attention to the typmod
value.  This seems needed in view of the fact that 8.3's generalized typmod
support will accept a lot of bogus syntax, such as "timestamp(foo)" or
"record(int, 42)" --- if we allow such things to pass without comment,
users will get confused.  Per a recent example from Greg Stark.

To implement this in a way that's not very vulnerable to future
bugs-of-omission, refactor the API of parse_type.c's TypeName lookup routines
so that typmod validation is folded into the base lookup operation.  Callers
can still choose not to receive the encoded typmod, but we'll check the
decoration anyway if it's present.
18 files changed:
src/backend/access/common/tupdesc.c
src/backend/commands/aggregatecmds.c
src/backend/commands/comment.c
src/backend/commands/functioncmds.c
src/backend/commands/opclasscmds.c
src/backend/commands/operatorcmds.c
src/backend/commands/prepare.c
src/backend/commands/tablecmds.c
src/backend/commands/typecmds.c
src/backend/parser/parse_expr.c
src/backend/parser/parse_func.c
src/backend/parser/parse_oper.c
src/backend/parser/parse_relation.c
src/backend/parser/parse_type.c
src/backend/parser/parse_utilcmd.c
src/backend/utils/misc/guc.c
src/include/parser/parse_type.h
src/pl/plpgsql/src/pl_comp.c