ECPG has several discrepancies between the documented connection
target formats and actual behavior. I'm preparing a documentation
patch as I previously mentioned in the recent Connection string
thread in pgsql-general, but before doing so I'd like to distinguish
documentation bugs from code bugs. Here are some differences I've
found:
1. [EMAIL PROTECTED]:port]
This suggests that dbname:port should work but ECPG interprets the
entire dbname:port string as the database name. I'm thinking
this is a documentation bug and the format should be shown as
[EMAIL PROTECTED]:port]]
Does anybody disagree?
2. tcp:postgresql://hostname[:port][/dbname][?options]
This suggests that tcp:postgresql://hostname[:port] should work
without specifying /dbname, and indeed it does work when the
connection target is a variable reference or a double-quoted string
literal. However, the connection name is then set to NULL, causing
segmentation faults on some systems (e.g., Solaris 9) if ECPG
debugging is enabled. When the target is an unquoted literal the
ECPG preprocessor fails with a syntax error. Is the latter case a
grammar bug or should the former case not be allowed?
The documentation doesn't mention anything about the options component
but the source code shows that this value is used as the third
argument to PQsetdbLogin(), which passes command-line options to
the postmaster. I suppose this should be documented, if only via
an example, although I wonder if anybody actually uses it.
3. unix:postgresql://hostname[:port][/dbname][?options]
Same as (2). Also, hostname must be localhost or 127.0.0.1
else the ECPG preprocessor fails if the target is an unquoted
literal, and if the target is double-quoted or a variable reference
then the connection attempt raises a segmentation fault at runtime.
One of the examples is unix:postgresql://sql.mydomain.com/...,
which I'll fix.
Incidentally, would anybody object to using example.com as the
domain name in examples? RFC 2606 Reserved Top Level DNS Names
reserves example.com and several other top- and second-level domains
for private testing, as examples in documentation, and the like.
4. an SQL string literal containing one of the above forms
Michael Meskes recently fixed ECPG to accept double-quoted C strings
but it currently doesn't accept single-quoted SQL strings. My reading
of the standard is that CONNECT TO should allow single-quoted strings,
as I mention here:
http://archives.postgresql.org/pgsql-general/2006-08/msg00838.php
Does anybody interpret the standard differently?
5. If you specify the connection target literally (that is, not through
a variable reference) and you don't quote the value, then the case-
insensitivity rules of normal SQL are applied.
ECPG's debugging mode and a packet sniff show that unquoted database
and user names are passed as written, so I'm not seeing how the
case-insensitivity rules are being applied. Should this be reworded
or omitted altogether? Or is there something I'm missing?
Other comments? Thanks.
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
