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)
commit92ad7dcfe289ce75e79f40170c1a99623e005ed8
tree00ab60bd1af1a07d2890a3575af7cea9ef4ecc66
parent0ca429cb649db30af178c88b06354e9d343cc77f
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