From: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Prefered Types |
Date: | 2011-05-09 03:41:38 |
Message-ID: | 541a621be3e08629266060a8ddd47718@biglumber.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Tom and I:
>>> BTW, not to rain on the parade or anything, but I'll bet that
>>> rejiggering anything at all here will result in whining that puts the
>>> 8.3-era removal of a few implicit casts to shame.
>> I'll take that bet, as it's really hard to imagine anything being worse
>> than the pain caused by 8.3 to many people using Postgres.
> You think? At least the 8.3 changes resulted in easily-diagnosed parser
> errors. The folks who complained about it were complaining because they
> couldn't be bothered to fix anything about their applications, not
> because it was difficult to understand or to fix.
Those of us in the trenches saw things a little differently. There's a
difference between "couldn't be bothered" and the sometimes herculean
task of changing an existing complicated code base, including finding
all the problems, fixing, writing tests, doing QA, etc. It was also
difficult to explain all this to clients: why their code worked just
fine on all previous versions, what the exact theoretical dangers
involved are (and agreeing that, yes, it doesn't really apply to
their particular code), and the sheer man-hours it was going to take
to get their application over the 8.3 hump. (Granted, there's the
system catalog hacks, but a) they introduce other problems and b)
it's dangerous to reapply constantly when pg_dumping or moving
across versions)
> It seems likely to me that any changes in function resolution behavior
> will result in failures that are *much* harder to diagnose. The
> actual fix might be the same (ie, insert an explicit cast or two)
> but back-tracking from the observed problem to that fix could be an
> order of magnitude more difficult. For example, if you start noticing
> an occasional integer overflow that didn't happen before, it might be
> pretty darn difficult to figure out that the problem is that an operation
> that was formerly resolved as int4 + int4 is now resolved as int2 + int2.
Have I mentioned I'm already a big -1 on the whole idea? :) Yes, this
will be a more subtle problem to diagnose, but I also think it will
affect less code and thus not elicit as much whining. Besides,
I never recommend clients use SMALLINT anyway. ("That type you are
using: I do not think it's as efficient as you think it is")
- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201105082312
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAk3HYk4ACgkQvJuQZxSWSshQ+ACePUFS++9q4lhsdWSolIqDuI+r
LY4AoOBsEszt1goBe73GBuSW+dt0DfWF
=gycE
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-05-09 07:14:39 | Re: Proposed patch: Smooth replication during VACUUM FULL |
Previous Message | Tom Lane | 2011-05-09 03:00:27 | Re: Prefered Types |