On Mon, Nov 04, 2013 at 02:34:02PM -0500, Tom Lane wrote: > Noah Misch <n...@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. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
