In this thread:
http://archives.postgresql.org/pgsql-sql/2007-11/msg00038.php
we saw that there is considerable new potential for user confusion
created by the 8.3 extensions to allow any type name to be decorated
with typmod parameters (which can be either constants or identifiers).
I see no problem if the typmod data is actually checked, but there
are various code paths that don't care about the typmod and thus don't
bother to check.
The problematic places are those that call LookupTypeName, typenameType,
or typenameTypeId, but don't bother to call typenameTypeMod. While we
could go around and fix just the buggy spots, I am thinking that will
leave us open to more errors of omission in the future. I am inclined
to refactor the API so that it's not possible to make this mistake,
by merging typenameTypeMod into the other entry points. I'd add a
parameter "int32 *typmod" to each of them, which could be passed as NULL
by callers that don't care about typmod, but the validation would still
be carried out.
I'm also a bit inclined to change LookupTypeName to return a Type struct
(ie, a syscache tuple) the way typenameType does, because it looks to me
like all callers either do or should look up the syscache entry anyway
--- in some cases only indirectly by calling get_typisdefined, but still
there are going to be multiple syscache fetches there if we don't change
the return value.
Comments?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
