Thread: ODBC functions in gram.y
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
Thomas Lockhart <lockhart@fourpalms.org> writes:
> 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.
It's not apparent to me that doing this in the ODBC support is simpler
or better than the hack Peter put into gram.y. But more importantly,
at this point in the 7.2 cycle we ought not be making any changes that
are not *essential* bug fixes. If you want to reorganize the support
for CURRENT_TIMESTAMP() like that, let's leave it for 7.3.
regards, tom lane
> It's not apparent to me that doing this in the ODBC support is simpler
> or better than the hack Peter put into gram.y.
?? We have a long standing design policy to not pollute SQL syntax with
ODBC cruft. And we have existing mechanisms to easily enable that,
delegating that compatibility layer to the ODBC driver where it belongs.
If we phrase this instead as an SQL syntax bug report it becomes even
clearer.
> But more importantly,
> at this point in the 7.2 cycle we ought not be making any changes that
> are not *essential* bug fixes. If you want to reorganize the support
> for CURRENT_TIMESTAMP() like that, let's leave it for 7.3.
*grumble* The support for this is already organized. I'm just suggesting
that we avoid arbitrarily damaging our design and implementation with an
arbitrary reorganization done in the 7.2 development cycle, and that we
fix it before it become embedded in a release.
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
>> But more importantly,
>> at this point in the 7.2 cycle we ought not be making any changes that
>> are not *essential* bug fixes. If you want to reorganize the support
>> for CURRENT_TIMESTAMP() like that, let's leave it for 7.3.
> *grumble* The support for this is already organized. I'm just suggesting
> that we avoid arbitrarily damaging our design and implementation with an
> arbitrary reorganization done in the 7.2 development cycle, and that we
> fix it before it become embedded in a release.
I hear you ... but I think the time to have complained was when Peter
put it in, which was nigh two months ago.
regards, tom lane
...
> I hear you ... but I think the time to have complained was when Peter
> put it in, which was nigh two months ago.
Yup. I did complain then (see archives) but apparently others did not
care to have an opinion at that time, and it was not fixed.
- Thomas
Hi ppl, Actually i am trying to locate the physical memeory location where a computation of a query is done e.g. if I am trying to find out the sum of 1000 record values of salaries and i want to know the actual physical location of the memory where the SPI (server programmimg Interface) allocates it through the Upper Memory Executer by the "palloc" funtion of 'C'. the whole idea is to retrieve the partial computation of the queries very through fast this memory location. regards, J. James __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
--- John James <john0012001us@yahoo.com> wrote: > > Hi ppl, > > Actually i am trying to locate the physical memeory > location where a computation of a query is done e.g. > if I am trying to find out the sum of 1000 record > values of salaries and i want to know the actual > physical location of the memory where the SPI > (server > programmimg Interface) allocates it through the > Upper > Memory Executer by the "palloc" funtion of 'C'. > > > the whole idea is to retrieve the partial > computation > of the queries very through fast this memory > location. > > regards, > J. James > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: you can get off all lists at once with the > unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
> ... > > I hear you ... but I think the time to have complained was when Peter > > put it in, which was nigh two months ago. > > Yup. I did complain then (see archives) but apparently others did not > care to have an opinion at that time, and it was not fixed. I think I complained too, but was told it was only a few lines of code, and that was OK. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Thomas Lockhart writes: > > It's not apparent to me that doing this in the ODBC support is simpler > > or better than the hack Peter put into gram.y. > > ?? We have a long standing design policy to not pollute SQL syntax with > ODBC cruft. But that doesn't apply in this case because we're augmenting SQL cruft with ODBC syntax. ;-) > And we have existing mechanisms to easily enable that, delegating that > compatibility layer to the ODBC driver where it belongs. I'm not a great fan of rewriting SQL code behind the scenes, especially not when it's a trivial case such as this. Moreover, developers of ODBC applications might wish to test their code in, say, psql. It's not like we're adding lisp syntax, we're only allowing parentheses after a function call -- like after all other function calls. -- Peter Eisentraut peter_e@gmx.net
OK, it is clear that you don't think it is important. But some do, and
are willing to do the work to maintain the ODBC driver and its features
in a consistant way. So it shouldn't be a problem, eh?
- Thomas
Thomas Lockhart writes: > OK, it is clear that you don't think it is important. But some do, and > are willing to do the work to maintain the ODBC driver and its features > in a consistant way. So it shouldn't be a problem, eh? As long as it works, more power to you. ;) Btw., the odbc.sql file still has some doubled-up lines from your interrupted commit. -- Peter Eisentraut peter_e@gmx.net
> As long as it works, more power to you. ;)
OK. btw, can you recall the use case for the CURRENT_xxx() syntax (with
parens)? ODBC officially defines synonyms for these functions which were
already supported by the driver. So some other application was
generating these function calls?
> Btw., the odbc.sql file still has some doubled-up lines from your
> interrupted commit.
Thanks. I'm fixing it now (but may have to wait a bit to get it
committed; the DSL line is still trouble).
- Thomas