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
(inodbc/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
