On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch <n...@leadboat.com> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
