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

Поиск
Список
Период
Сортировка
От Benjamin Scherrey
Тема Re: trouble caused by change in 7.3 handling of '' in
Дата
Msg-id SOKJ31XT31XE0HBXUJE32DB75FAT6.3e01058e@BONZO
обсуждение исходный текст
Ответ на Re: trouble caused by change in 7.3 handling of '' in  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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@candle.pha.pa.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@candle.pha.pa.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@postgresql.org so that your
>message can get through to the mailing list cleanly
>




В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Regarding select distinct ...query
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Measuring CPU time use? (Another stupid question)