Re: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
От | Thomas Lockhart |
---|---|
Тема | Re: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards |
Дата | |
Msg-id | 3B218973.EB2F7E3C@alumni.caltech.edu обсуждение исходный текст |
Ответ на | AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
> > Clearly it is not the case that "this kluge surprises everyone except > > those who already know it exists." > How can you argue that, when the topic comes up again every couple of > months? I'm not looking for an argument. But the statement is not factually true: "suprises everyone" (most folks don't notice, and don't care much) and "every couple of months" (??) stray far enough from facts that we should get back on topic. Whatever the facts, the messages that we do *not* get are just as significant: a relatively large portion of feedback from users of both Access and PostgreSQL at the time the "feature" was added indicated that it was a significant stumbling block for those users, and those messages will start up anew without adequate planning and implementation. Since back then, we have some additional clarification that it occurs only for users of Access/Forms, and that others are worried that it will lead to difficulties for others under different circumstances (please remember, or note if it is too long ago, that at the time I argued against adding the "feature", but tried to listen to those who would find it useful). I'm not ignoring those worries, but in the battle between purity and usefulness we shouldn't always line up with the strongest or loudest voice(s) that day, but try to respect and keep in mind the others who have contributed to the discussion in the past. That said, the issues should be broken down into managable chunks, but imho forcing the last step (removal of the "= NULL" accomodation) first is premature. How about phasing this so that we can accomodate the long-standing issue of M$ interoperability (via ODBC improvements to make it transparent) before ripping out the current workaround? From Andreas' comments, it seems that for his application he would like a different behavior, but frankly I'm not certain why the current behavior would be detrimental in the use case he mentioned. If SQL92 requires that any query with "= NULL" be rejected as illegal (my books aren't nearby at the moment), he might still want to have code at the application level for some graceful handling of illegal values. - Thomas
В списке pgsql-hackers по дате отправления: