From: | Benjamin Scherrey <scherrey(at)proteus-tech(dot)com> |
---|---|
To: | Larry Rosenman <ler(at)lerctr(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Vivek Khera <khera(at)kcilink(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: trouble caused by change in 7.3 handling of '' in |
Date: | 2002-12-18 23:32:30 |
Message-ID: | SOKJ31XT31XE0HBXUJE32DB75FAT6.3e01058e@BONZO |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
These incompatibilities have been caused by better compliance with standards, right? If
this is the case then I don't think you want to go backwards. Indeed - as a software developer, I
always test my code on pending betas just to see what's going to change before a major release
gets to the general public so my app will already be compliant. To be competitive with the major
RDBMS' this kind of progress needs to be made.
If the postgres developers want to put app developers on notice perhaps they can adopt
a deprecation policy where whenever a feature is going to be removed or changed in a manner
that breaks existing code the following steps should be taken:
1. next release announce it as deprecated and produce a warning message whenever
it's used. if it's major, possible provide a compile option --with<newfun/behaviour> so users can test
it.
2. the following release remove or make the change. if it's major, possibly provide a
compile option --with-<oldfunc/behaviour> so users can temporarily keep the old behaviour.
3. the following release - its done/gone/never to return again
Any app developer/user who can't follow this stable plan isn't interested in a better
postgres anyway.
best regards,
Ben Scherrey
PS: FWIW - it was a bit annoying for "where x = null" to break silently for my client's code. A
deprecation warning/error would have made their app debugging very quick rather than wondering
why their database broke (when it didn't).
12/18/2002 5:28:37 PM, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
>Larry Rosenman wrote:
>> That explains why my RT started acting wierd (it's in test).
>>
>> This also breaks PHPGroupware as well. (I've reported it to them).
>>
>> Is there any way to get this to be a postgresql.conf option for transition?
>
>Oh, wow, we have two now. We did discuss the problems of backward
>compatibility, but didn't think it would effect many people.
>
>Folks, what do you want to do?
>
>--
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>message can get through to the mailing list cleanly
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-12-18 23:38:16 | Re: Measuring CPU time use? (Another stupid question) |
Previous Message | Tom Lane | 2002-12-18 23:27:24 | Re: Regarding select distinct ...query |