Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet.
Date
Msg-id 26779.1383593642@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet.  (Noah Misch <noah@leadboat.com>)
Responses Re: pgsql: Remove internal uses of CTimeZone/HasCTZSet.  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Fri, Nov 01, 2013 at 04:51:34PM +0000, Tom Lane wrote:
>> Remove internal uses of CTimeZone/HasCTZSet.

> This changed EncodeDateTime() output for USE_SQL_DATES and USE_GERMAN_DATES
> styles, because it inserts a space before "tzn" but does not insert a space
> before EncodeTimezone() output.  Example:

>   set datestyle = sql,mdy;
>   select '2013-01-01'::timestamptz;

> old output:

>       timestamptz       
> ------------------------
>  01/01/2013 00:00:00+00

> new output:

>        timestamptz
> -------------------------
>  01/01/2013 00:00:00 +00

> I assume this was unintended.

Yeah, I had seen some cases of that.  I don't find it of great concern.
We'd have to insert some ugly special-case code that looks at the zone
name to decide whether to insert a space or not, and I don't think it'd
actually be an improvement to do so.  (Arguably, these formats are
more consistent this way.)  Still, this change is probably a sufficient
reason not to back-patch this part of the fix.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #8573: int4range memory consumption
Next
From: Gavin Flower
Date:
Subject: Re: Fast insertion indexes: why no developments