Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Just a freshing for clean applying..
> http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
> Is any objections to commit?
There's still a lot I don't particularly care for here (lack of
documentation being the biggest), but I'll make a pass at cleaning it up.
One thought I had after a quick reading of the patch is that there
doesn't seem to be a whole lot of percentage in trying to move the
typmod handling for time/timestamp/interval types into callable
functions, because we still have to special-case the darn things
thanks to the SQL spec's oddball syntax requirements. For instance
in format_type_be() you've got
case TIMETZOID:
if (with_typemod)
! buf = psnprintf(50, "time(%d) with time zone",
! typemod);
else
buf = pstrdup("time with time zone");
break;
changed to
case TIMETZOID:
if (with_typemod)
! buf = printTypmod("time", typemod, typeform->typmodoutput);
else
buf = pstrdup("time with time zone");
break;
which hardly seems like much of an improvement. If we could have gotten
rid of the switch() branch for TIMETZOID entirely, then we'd be
somewhere, but there's no chance because the typmod-less case still has
to be special. So I'm sort of inclined to leave the processing of these
datatypes as-is, and only use the typmodin/typmodout infrastructure for
datatypes that follow the "canonical" syntax of type_name(int[,int ...]).
Thoughts?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
