Re[2]: [HACKERS] Re: [INTERFACES] Odbc parser error

Hello Thomas,

lunedì, 26 ottobre 98, you wrote:

>> JS> Yes, I would to suggest a way to solve this problem because in
>> JS> Access we can't link two tables by a numeric field
>> JS> # conn=75511800, query='SELECT "order_detail"."numero" FROM
>> JS> "order_detail" WHERE ("numero" = NULL )'
>> JS> I know this is not standard but Access understand both syntaxes
>> JS> SELECT * FROM table WHERE field IS NULL;
>> JS> SELECT * FROM table WHERE field = NULL;
>> JS> Why not to get PostgreSQL to understand it also ?
>> Done. I modify the pgsql/src/backend/gram.y
>> How about to add it to official release ?

TGL> Or, how about insisting that your commercial software suppliers conform
TGL> to one of the simplest and clearest part of the SQL standard they claim
TGL> to support? Instead of using those suppliers who insist on making small
TGL> and large incompatibilities in their popular software packages to ensure
TGL> that only their own products can interoperate with them?

You are right Tom, but you know there is no way to have something from
those bastards, I prefer to talk with a wall.

TGL> *slap* Ow! Ok, Ok!

TGL> It looks like a nice patch. But it is too late to get it into v6.4. It
TGL> looks like a good addition to v6.5...

TGL> *slap* OW! OK!

TGL> In fact, it is such a nice feature that I'm sure it will fit nicely into
TGL> v6.4.1, and you are welcome to submit a patchset to post on
TGL> postgresql.org to fix v6.4.

TGL> *grin*

TGL> It would be best to include patches for both gram.y and a full gram.c so
TGL> that users may not have to rebuild the parser. Also, if we run into
TGL> parser syntax conflicts in the future it would be a candidate for
TGL> removal, I suppose.

Should I send the patch now or after v6.4 is released ?

Jose'