pgsql-server/ oc/src/sgml/libpq.sgml rc/interf ...

Started by Tom Lanealmost 23 years ago3 messagescomitters
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@svr1.postgresql.org 03/10/04 18:05:22

Modified files:
doc/src/sgml : libpq.sgml
src/interfaces/libpq: fe-exec.c

Log message:
Document the always-true-but-previously-undocumented fact that PQfnumber()
will downcase the supplied field name unless it is double-quoted. Also,
upgrade the routine's handling of double quotes to match the backend,
in particular support doubled double quotes within quoted identifiers.
Per pgsql-interfaces discussion a couple weeks ago.

#2Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#1)
Re: pgsql-server/ oc/src/sgml/libpq.sgml rc/interf ...

Tom Lane writes:

Document the always-true-but-previously-undocumented fact that PQfnumber()
will downcase the supplied field name unless it is double-quoted. Also,
upgrade the routine's handling of double quotes to match the backend,
in particular support doubled double quotes within quoted identifiers.

Isn't that an instance of the same "buggy" behavior that the database name
provided to libpq once exhibited, i.e., it should be removed?

Per pgsql-interfaces discussion a couple weeks ago.

Could I request that technical decisions that are reached somewhere in the
depth of threads on user-level mailing lists are posted to hackers before
they are applied?

--
Peter Eisentraut peter_e@gmx.net

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#2)
Re: pgsql-server/ oc/src/sgml/libpq.sgml rc/interf ...

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

Document the always-true-but-previously-undocumented fact that PQfnumber()
will downcase the supplied field name unless it is double-quoted. Also,
upgrade the routine's handling of double quotes to match the backend,
in particular support doubled double quotes within quoted identifiers.

Isn't that an instance of the same "buggy" behavior that the database name
provided to libpq once exhibited, i.e., it should be removed?

Well, we can re-discuss it if you like. I'd have preferred that answer
myself, but it didn't seem to be the winner in the pg-interfaces discussion.

Per pgsql-interfaces discussion a couple weeks ago.

Could I request that technical decisions that are reached somewhere in the
depth of threads on user-level mailing lists are posted to hackers before
they are applied?

As far as I'm concerned, pgsql-interfaces is an appropriate and
sufficiently authoritative discussion forum for issues that only affect
the interface libraries and not the backend. If we aren't willing to
delegate, we might as well eliminate all the other lists and just have
pgsql-hackers.

regards, tom lane