pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRe[2]: [HACKERS] Re: [INTERFACES] Odbc parser error
2+ messages / 1 participants
[nested] [flat]
* Re[2]: [HACKERS] Re: [INTERFACES] Odbc parser error
@ 1998-10-26 16:22 Sferacarta Software <sferac@bo.nettuno.it>
0 siblings, 0 replies; 2+ messages in thread
From: Sferacarta Software @ 1998-10-26 16:22 UTC (permalink / raw)
To: Byron Nikolaidis <byronn@insightdist.com>; +Cc: pgsql-hackers@postgresql.org
Hi all,
JS> Yes, I would to suggest a way to solve this problem because in Access we
JS> can't link two tables
JS> by a numeric field, for example:
JS> I have 2 tables:
JS> ORDER_MASTER: ORDER_DETAIL:
JS> -------------- --------------
JS> numero SERIAL <---> numero SERIAL
JS> ... ...
JS> When I try to create a new ORDER, the connection goes down with message:
JS> # conn=75511800, query='SELECT "order_detail"."numero" FROM
JS> "order_detail" WHERE ("numero" = NULL )'
JS> # ERROR from backend during send_query: 'ERROR: parser: parse error at
JS> or near "null"'
JS> I know this is not standard but Access understand both syntaxes (i.e.:
JS> SELECT * FROM table WHERE field IS NULL; = SELECT * FROM table
JS> WHERE field = NULL;
JS> SELECT * FROM table WHERE field IS NOT NULL; = SELECT * FROM table
JS> WHERE field <> NULL;
JS> Why not to get PostgreSQL to understand it also ?
Done. I modify the pgsql/src/backend/gram.y at line 3318 I inserted
the following two lines:
<DELETED>
3318 | a_expr '=' NULL_P
3319 { $$ = makeA_Expr(ISNULL, NULL,$1, NULL);
3320 | a_expr '=' a_expr
3321 { $$ = makeA_Expr(OP, "=", $1, $3); }
<DELETED>
now SELECT * FROM table WHERE field IS NULL;
is the same as: SELECT * FROM table WHERE field = NULL;
How about to add it to official release ?
-------------------------------------------------------------------
I think I found a bug using IS NULL operator:
hygea=> \d comuni
Table = comuni
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| istat | char() not null | 6 |
| nome | char() | 50 |
| provincia | char() | 2 |
| codice_fiscale | char() | 4 |
| cap | char() | 5 |
| regione | char() | 3 |
| distretto | char() | 4 |
+----------------------------------+----------------------------------+-------+
hygea=> select * from comuni where COMUNI is null;
^^^^^^------------------COMUNI is
not a field but the table name.
istat|nome|provincia|codice_fiscale|cap|regione|distretto
-----+----+---------+--------------+---+-------+---------
(0 rows)
Jose'
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re[2]: [HACKERS] Re: [INTERFACES] Odbc parser error
@ 1998-10-27 15:01 Sferacarta Software <sferac@bo.nettuno.it>
0 siblings, 0 replies; 2+ messages in thread
From: Sferacarta Software @ 1998-10-27 15:01 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-hackers@postgresql.org
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'
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~1998-10-27 15:01 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-10-26 16:22 Re[2]: [HACKERS] Re: [INTERFACES] Odbc parser error Sferacarta Software <sferac@bo.nettuno.it>
1998-10-27 15:01 Re[2]: [HACKERS] Re: [INTERFACES] Odbc parser error Sferacarta Software <sferac@bo.nettuno.it>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox