Re: trouble caused by change in 7.3 handling of '' in

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
>

In response to

Browse pgsql-general by date

  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