pgsql/ oc/src/sgml/installation.sgml oc/src/sg ...

CVSROOT: /cvsroot
Module name: pgsql
Changes by: petere(at)postgresql(dot)org 01/10/09 18:32:33

Modified files:
doc/src/sgml : installation.sgml odbc.sgml
src/backend/parser: gram.y
src/interfaces/odbc: GNUmakefile odbc.sql

Log message:
Allow optional () after current_user, session_user, user, current_time,
current_timestamp, current_date for ODBC compatibility.

Add more functions to odbc.sql catalog extension, use new CREATE OR
REPLACE FUNCTION.

Document iODBC/unixODBC build options.

petere(at)postgresql(dot)org writes:
> Allow optional () after current_user, session_user, user, current_time,
> current_timestamp, current_date for ODBC compatibility.

Allow me to register an objection to this having been done with zero
discussion, especially on the very eve of a beta release. It's not
apparent to me that this is an improvement in our standards
compatibility.

regards, tom lane

Tom Lane writes:

> > Allow optional () after current_user, session_user, user, current_time,
> > current_timestamp, current_date for ODBC compatibility.
>
> Allow me to register an objection to this having been done with zero
> discussion, especially on the very eve of a beta release.

I apologize.

> It's not apparent to me that this is an improvement in our standards
> compatibility.

ODBC is generally thought of as being a standard.

We've had these in the odbc.sql file in semi-disabled form because they
needed parser support.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter

> Tom Lane writes:
>
> > > Allow optional () after current_user, session_user, user, current_time,
> > > current_timestamp, current_date for ODBC compatibility.
> >
> > Allow me to register an objection to this having been done with zero
> > discussion, especially on the very eve of a beta release.
>
> I apologize.
>
> > It's not apparent to me that this is an improvement in our standards
> > compatibility.
>
> ODBC is generally thought of as being a standard.
>
> We've had these in the odbc.sql file in semi-disabled form because they
> needed parser support.

Seems fine to me.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>> Allow optional () after current_user, session_user, user, current_time,
>>> current_timestamp, current_date for ODBC compatibility.

>> It's not apparent to me that this is an improvement in our standards
>> compatibility.

> ODBC is generally thought of as being a standard.

True ... if it's okay with Thomas then I won't object.

regards, tom lane

> >>> Allow optional () after current_user, session_user, user, current_time,
> >>> current_timestamp, current_date for ODBC compatibility.
> >> It's not apparent to me that this is an improvement in our standards
> >> compatibility.
> > ODBC is generally thought of as being a standard.
> True ... if it's okay with Thomas then I won't object.

ODBC is a standard, but not the standard targeted by our implementation
of SQL in the backend, and does not *require* direct support for all
features in the backend. In some cases, we solve that in the ODBC
driver, with perhaps help from extensions defined in odbc.sql.

SQL99 indicates that an argument between parens is required, so this
would be an extension to that standard. Also, if we agree that this
extension must be in the backend because the ODBC driver cannot
implement it (I'm not certain about that; it looks pretty reasonable to
fit it in with a few changes to the mapFunction() routine) then I'd like
to see it implemented as part of the original CURRENT_TIME(arg)
definition, not as a completely separate rule (or did you get
shift/reduce conflicts trying it that way?).

- Thomas

> > >>> Allow optional () after current_user, session_user, user, current_time,
> > >>> current_timestamp, current_date for ODBC compatibility.
> > >> It's not apparent to me that this is an improvement in our standards
> > >> compatibility.
> > > ODBC is generally thought of as being a standard.
> > True ... if it's okay with Thomas then I won't object.
>
> ODBC is a standard, but not the standard targeted by our implementation
> of SQL in the backend, and does not *require* direct support for all
> features in the backend. In some cases, we solve that in the ODBC
> driver, with perhaps help from extensions defined in odbc.sql.
>
> SQL99 indicates that an argument between parens is required, so this
> would be an extension to that standard. Also, if we agree that this
> extension must be in the backend because the ODBC driver cannot
> implement it (I'm not certain about that; it looks pretty reasonable to
> fit it in with a few changes to the mapFunction() routine) then I'd like
> to see it implemented as part of the original CURRENT_TIME(arg)
> definition, not as a completely separate rule (or did you get
> shift/reduce conflicts trying it that way?).

That is a good argument. Seems isolating it in the ODBC code would be
optimal. Does that mean that SQL99 doesn't like now() and functions
with no arguments?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> ODBC is a standard, but not the standard targeted by our implementation
> of SQL in the backend, and does not *require* direct support for all
> features in the backend. In some cases, we solve that in the ODBC
> driver, with perhaps help from extensions defined in odbc.sql.

Good point. Mapping CURRENT_USER() to CURRENT_USER in the ODBC driver
would be more standards-compliant than doing it in the backend, IMHO.

regards, tom lane

Thomas Lockhart writes:

> ODBC is a standard, but not the standard targeted by our implementation
> of SQL in the backend, and does not *require* direct support for all
> features in the backend.

The backend supports all kinds of things. We have redundant compatibility
syntax for Oracle, MS-SQL, we even broke backward compatibility to support
MySQL, and we have confused users for years with MS Access compatibility.
None of these are standards.

Meanwhile, this new syntax is a tiny change, completely compatible, and
actually makes more sense rather than less from an overall consistency
point of view. (If the change were allowing leaving off the parentheses
things would have been completely different.)

> I'd like to see it implemented as part of the original
> CURRENT_TIME(arg) definition, not as a completely separate rule (or
> did you get shift/reduce conflicts trying it that way?).

This way it was the least amount of change and the rules could be reused
for session_user and such.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter