i'm recently under impression that pg developers are overprotective. who do they protect?
i mean – don't get me wrong – i live with, and (to some extent) thanks to the piece of marvelous technology which is postgresql ordbms.
i use it, i try to help other use it. i don't think there is any better database available now (at the very least – for my purposes).
but, just lately, i some to see some cases where decissions are made in a way to “protect us (dbas) from our faults".
two examples which i personally find important are:
- lack of hints (which i already ranted about)
- removing automatic casts int/text in 8.3
in first case – reasoning is simple – it is not good! we will make the planner do better, and you dont need it. using it will harm you, make you loose your ti
me, and so on.
fine. the argument is there. but (for me) – it is nothing more than overprotecting users. if user wants to do something that is potentially dangerous or even
pointless – i think it would be much better to tell him that he can shoot himself in a foot, but, by all means – let him do it!
unix system for longest time permit (to superusers) access to raw disks (think /dev/hda in linux). a lot of people got burned by this (including me). but the
feature is still a feature. and nobody advocates removing it.
even in postgresql – there is “fsync=off" setting which is potentially dangerous, and (to some extent) pointless (with smart raid controllers with battery-back
then – the automatic casts.
“since always" you could do something like this:
create table x (id text primary key); insert into x (...); select * from x where id = 123;
and it worked. it was not perfect. i don't think i ever made a table with textual primary key.
but, some people, somewhere did. seen that.
and now, their code will stop working, because it was “discovered" that “text = int" is not actually clearly defined.
so, instead of defining it in any way (for example, the way it always worked) – it was made illegal.
justification? such code is broken anyway.
what will happen is that there will be (there are) some databases which do use something like this. and they will not be “upgradeable".
maintainer doesn't work here anymore, it's too complex, nobody wants to touch it, we've got better things to do than to find and fix every possible mistake in the code – there are even more possible (and, business-wise, valid) reasons.
this will lead to people get “stuck" at 8.2. which is great database. now. but what about “in 5 years"? right now, when somebody asks a question on mailing lists, saying that he's using 7.x, he gets prompt suggestion: upgrade, 8.x is soooo much better.
i bet the same will happen with 8.2. and any other future version.
so again – core team decided that it's better to protect us from ambiguity, than:
- leaving things the way there were
- and/or: putting into bible/manual how it exactly works, thus removing all possible ambiguity from the case
- or making a poll which will tell which way it should work, than make it so.
do you think it's ok? i'm not so sure.
the problem with it is that i never made my databases that way – so i'm not really into advocating against the change. but i can easily feel the pain of people who will be banned from future improvements in postgresql code, but the simple fact that once in their application-life-time, they made a mistake. and then – they didn't have time nor resources to fix it.
what i'd like to advocate though is, that i would love to have zillions of dangerous “knobs and switches" in postgresql. the ones that go deep inside the engine, and change things that are dangerous, but can be used to do something a bit better.
of course – we would need big and bold warning labels: “do not touch this, this will destroy your data!", but – same goes with /dev/hda or fsync=off.