From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200506240432.j5O4WF026888@candle.pha.pa.us>
Subject: Re: empty view, replace view, column type change?
In-Reply-To: <8931.1119565282@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 24 Jun 2005 00:32:15 -0400 (EDT)
Cc: Rod Taylor <pg@rbt.ca>, Markus Bertheau <twanger@bluetwanger.de>,
	PgSQL - SQL <pgsql-sql@postgresql.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Tom Lane wrote:
> > If you SELECT 'abc'::varchar(6)::varchar, the end type is varchar(6).
> 
> Yeah, this is exactly what's happening --- if you look at gram.y,
> LOCALTIMESTAMP is expanded to "'now'::text::timestamp(6)".  I am
> unconvinced that the (6) is a very good idea though.  The code says
> 
>                     /* SQL99 mandates a default precision of 6 for timestamp.
>                      * Also, that is about as precise as we will get since
>                      * we are using a microsecond time interface.
>                      * - thomas 2001-12-07
>                      */
>                     d->typmod = 6;
> 
> but it doesn't seem to me to follow from what the spec says that we need
> to explicitly cast the result of now() to six places.  As long as it's
> coming from gettimeofday it can't have more than 6 places anyway, and so
> we might as well save the extra coercion step.  (The parser *will* tack
> on a separate coercion function call when presented with this parse
> tree.)
> 
> In short, I'm inclined to remove the above-quoted lines, and similarly
> for CURRENT_TIME, CURRENT_TIMESTAMP, and LOCALTIME.  Thoughts?

Agreed.  That "6" bothered me too when I was cleaning up the timestamp
code a while back.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073