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

Fri, 07 Dec 2001 16:43:14 +0000
Thomas Lockhart <lockhart@fourpalms.org>
ODBC functions in gram.y
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

Fri, 07 Dec 2001 12:20:45 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: ODBC functions in gram.y 
> 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

Fri, 07 Dec 2001 17:41:13 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Re: ODBC functions in gram.y
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

Fri, 07 Dec 2001 12:46:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: ODBC functions in gram.y 
...
> 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

Fri, 07 Dec 2001 18:01:56 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Re: ODBC functions in gram.y

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

Sat, 8 Dec 2001 01:41:01 -0800 (PST)
John James <john0012001us@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

Sat, 8 Dec 2001 04:07:04 -0800 (PST)
John James <john0012001us@yahoo.com>
mapping physical memeory space
> ...
> > 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, Pennsylvania 19026

Mon, 10 Dec 2001 05:50:59 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: ODBC functions in gram.y
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


Mon, 10 Dec 2001 14:09:19 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: ODBC functions in gram.y
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

Mon, 10 Dec 2001 16:33:27 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Re: ODBC functions in gram.y
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


Tue, 11 Dec 2001 12:22:48 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: ODBC functions in gram.y
> 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

Tue, 11 Dec 2001 14:41:46 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Re: ODBC functions in gram.y