Re: Prefered Types - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Prefered Types
Date
Msg-id 541a621be3e08629266060a8ddd47718@biglumber.com
Whole thread Raw
In response to Re: Prefered Types  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@turnstep.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-----




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Prefered Types
Next
From: Mitsuru IWASAKI
Date:
Subject: Re: patch for new feature: Buffer Cache Hibernation