Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Bundle of patches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Bundle of patches
Date: 2006-12-29 17:21:56
Message-ID: 13803.1167412916@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Teodor Sigaev <teodor(at)sigaev(dot)ru> 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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-12-29 17:27:38
Subject: Re: [HACKERS] [BUGS] BUG #2846: inconsistent and confusing
Previous:From: Roman KononovDate: 2006-12-29 17:11:29
Subject: Re: [HACKERS] [BUGS] BUG #2846: inconsistent and confusing

pgsql-patches by date

Next:From: Tom LaneDate: 2006-12-29 17:27:38
Subject: Re: [HACKERS] [BUGS] BUG #2846: inconsistent and confusing
Previous:From: Roman KononovDate: 2006-12-29 17:11:29
Subject: Re: [HACKERS] [BUGS] BUG #2846: inconsistent and confusing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group