On Tue, Jan 24, 2012 at 11:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I do wonder whether we are making a mountain out of a mole-hill here,
> though. If I properly understand the proposal on the table, which
> it's possible that I don't, but if I do, the new format is
> self-identifying: when the optimization is in use, it sets a bit that
> previously would always have been clear. So if we just go ahead and
> change this, clients that have been updated to understand the new
> format will work just fine. The server uses the proposed optimization
> only for arrays that meet certain criteria, so any properly updated
> client must still be able to handle the case where that bit isn't set.
> On the flip side, clients that aren't expecting the new optimization
> might break. But that's, again, no different than what happened when
> we changed the default bytea output format. If you get bit, you
> either update your client or shut off the optimization and deal with
> the performance consequences of so doing.
Well, the bytea experience was IMNSHO a complete disaster (It was
earlier mentioned that jdbc clients were silently corrupting bytea
datums) and should be held up as an example of how *not* to do things;
it's better to avoid having to depend on the GUC or defensive
programmatic intervention to prevent further occurrences of
application failure since the former doesn't work and the latter won't
be reliably done. Waiting for applications to break in the field only
to point affected users at the GUC is weak sauce. It's creating a
user culture that is terrified of database upgrades which hurts
everybody.
Database apps tend to have long lives in computer terms such that they
can greatly outlive the service life of a particular postgres dot
release or even the programmers who originally wrote the application.
I'm not too concerned about the viability of a programming department
with Robert Haas at the helm, but what about when he leaves? What
about critical 3rd party software that is no longer maintained?
In regards to the array optimization, I think it's great -- but if you
truly want to avoid blowing up user applications, it needs to be
disabled automatically.
merlin