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 6: explain analyze is your friend