ODBC functions in gram.y

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: ODBC functions in gram.y
Date: 2001-12-07 16:43:14
Message-ID: 3C10F1A2.8A6EC580@fourpalms.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm looking at gram.y to munge the precision support for date/time per
recent discussions, and am noticing once again the extensions added to
support ODBC by allowing empty parens after some SQL-defined "constants"
(e.g. CURRENT_TIMESTAMP, CURRENT_USER, etc etc). Currently, these are
done by replicating code and by altering the allowed grammar, and it
happens to be the same area of code I need to be looking at.

There is are existing mechanisms for supporting ODBC function mappings
and function extensions which do not require altering gram.y. I would
propose that we use these mechanisms for this case.

The mechanisms are:

1) remap function names in the ODBC driver (odbc/convert.c; trivial).
2) define (some) new functions as SQL functions (in odbc/odbc.sql;
trivial).

The remapped function names from (1) either already exist in PostgreSQL,
or are newly defined in odbc.sql. For the particular cases gram.y was
altered to support, the ODBC function names conflict in our grammar, so
they should be mapped to a non-conflicting name. For example, to support
*ODBC* syntax CURRENT_TIMESTAMP() (illegal in SQL99), we would add a
mapping in convert.c as

"CURRENT_TIMESTAMP", odbc_timestamp

and then augment odbc.sql to include

create or replace function odbc_timestamp() returns timestamp as '
select current_timestamp;
' language 'sql';

This can be done with the other half dozen or so functions now in
gram.y.

Comments?

- Thomas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2001-12-07 17:07:40 Re: Using Cursor in PostgreSQL 7.2
Previous Message Thomas Lockhart 2001-12-07 16:14:52 Third call for platform testing