Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch <n...@leadboat.com> wrote:
>> 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.
I don't believe that. You are talking about the intersection of
(1) people who use a "brute force" timezone (which we already know is
a small set, else the original bug would've been noticed long ago).
(2) people who use "SQL" or "German" datestyle, neither of which is
default.
(3) people whose apps will fail if there's whitespace at a specific place
in timestamp output, even though in many other cases there will be
whitespace at that place anyway, notably including the case where they
select any regular timezone.
It's possible that this intersection is nonempty, but "huge amount"?
Come on. This is minor compared to the application compatibility
issues we come up with in every major release. More, I would argue
that the number of failing applications is likely to be exceeded by
the number that no longer fail upon selection of a brute-force zone,
because they'd only ever been coded or tested with the normal-zone-name
formatting.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
