On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch <noah@leadboat.com> wrote:
> On Mon, Nov 04, 2013 at 02:34:02PM -0500, Tom Lane wrote:
>> 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.
>
> I was prepared to suppose that no substantial clientele relies on the
> to_char() "TZ" format code expanding to blank, the other behavior that changed
> with this patch. It's more of a stretch to figure applications won't stumble
> over this new whitespace. I do see greater consistency in the new behavior,
> but changing type output is a big deal. While preserving the old output does
> require ugly special-case code, such code was in place for years until removal
> by this commit and the commit following it. Perhaps making the behavior
> change is best anyway, but we should not conclude that decision on the basis
> of its origin as a side effect of otherwise-desirable refactoring.
I have to admit I fear this will break a huge amount of application code.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
