Thread: libpq PGHOST

The current behaviour of libpq is to use Unix sockets whenever the host
parameter (PGHOST or setdbLogin argument) is NULL/unset.

Could we extend that to also use Unix sockets if the parameter is set but
empty?  That could avoid a bunch of shell contortions; e.g., you can't
portably un-export variables, in some shells you don't even have "unset".

Or would this be too incompatible?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> The current behaviour of libpq is to use Unix sockets whenever the host
> parameter (PGHOST or setdbLogin argument) is NULL/unset.
> Could we extend that to also use Unix sockets if the parameter is set but
> empty?

Seems reasonable, since the current behavior in that case is useless:

$ PGHOST='' psql
psql: connectDBStart() --  unknown hostname:
$

Backwards compatibility with that doesn't seem necessary ...
        regards, tom lane

Tom Lane writes:

> > The current behaviour of libpq is to use Unix sockets whenever the host
> > parameter (PGHOST or setdbLogin argument) is NULL/unset.
> > Could we extend that to also use Unix sockets if the parameter is set but
> > empty?
> Seems reasonable, since the current behavior in that case is useless:
> $ PGHOST='' psql
> psql: connectDBStart() --  unknown hostname:
> $
> Backwards compatibility with that doesn't seem necessary ...

After further investigation, there seems to be a larger unset/empty mess. 
When using PQconnectdb(), a NULL parameter (keyword was not given at all)
means to use the environment variable, an explicit empty argument is used
as is.  When using PGsetdbLogin(), however both NULL and empty arguments
cause the environment variable to be used.  (An environment variable is
always used as is.)

Consequently, if PGHOST is set in the environment and your application is
using PGsetdbLogin(), then it's just impossible to get a Unix socket
connection.

(Note that this is independent of the proposed change, because PGHOST may
be set to some "real" string that you might wish to override.)

If we were to sort this out, then I think we'd need to change
PQsetdbLogin() to take empty arguments uniformly "as is", and make the
change to make Unix sockets also with an empty host parameter, as
proposed.  Then you could use psql -h '' to request a Unix socket
explicitly.


Somewhat related:

peter=# create function "" () returns int as 'select 42' language 'sql';
CREATE
peter=# select ""();
----42
(1 row)

That was probably not the plan.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> If we were to sort this out, then I think we'd need to change
> PQsetdbLogin() to take empty arguments uniformly "as is", and make the
> change to make Unix sockets also with an empty host parameter, as
> proposed.  Then you could use psql -h '' to request a Unix socket
> explicitly.

Seems reasonable.

> peter=# create function "" () returns int as 'select 42' language 'sql';
> CREATE
> peter=# select ""();
> ----
>  42
> (1 row)

> That was probably not the plan.

I don't see any clear statement in SQL92 that <delimited identifiers>
can't have zero length, so I'm not convinced there's anything wrong here.
        regards, tom lane

Tom Lane writes:

> I don't see any clear statement in SQL92 that <delimited identifiers>
> can't have zero length, so I'm not convinced there's anything wrong here.

Hmm, I do:
        <delimited identifier> ::=             <double quote> <delimited identifier body> <double quote>
<delimitedidentifier body> ::= <delimited identifier part>...        <delimited identifier part> ::=
<nondoublequotecharacter>             | <doublequote symbol>
 

As opposed to, say, an empty character string literal:
        <character string literal> ::=             [ <introducer><character set specification> ]             <quote> [
<characterrepresentation>... ] <quote>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^               [ {
<separator>...<quote> [ <character representation>... ] <quote> }... ] 
 

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I don't see any clear statement in SQL92 that <delimited identifiers>
>> can't have zero length, so I'm not convinced there's anything wrong here.

> Hmm, I do:

>          <delimited identifier> ::=
>               <double quote> <delimited identifier body> <double quote>
>          <delimited identifier body> ::= <delimited identifier part>...
>          <delimited identifier part> ::=
>                 <nondoublequote character>
>               | <doublequote symbol>

> As opposed to, say, an empty character string literal:

>          <character string literal> ::=
>               [ <introducer><character set specification> ]
>               <quote> [ <character representation>... ] <quote>
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                 [ { <separator>... <quote> [ <character representation>... ] <quote> }... ] 

Hmm, you're right --- if they meant to allow zero-length identifiers
they'd have written something like
        <delimited identifier> ::=             <double quote> [ <delimited identifier body> ] <double quote>

I stand corrected.

Next question is do we want to change it?  I can't imagine any real good
use for a null-string name, but is there any risk of breaking existing
applications?

The actual fix would be trivial --- just introduce a complaint for
strlen(literalbuf)==0 into parser/scan.l's <xd>{xdstop} rule.
I'm just wondering if we should change or not.
        regards, tom lane

Tom Lane writes:

> Next question is do we want to change it?  I can't imagine any real good
> use for a null-string name, but is there any risk of breaking existing
> applications?

I think the larger risk is breaking applications if we leave it this way.  
One such broken application is the format_type function and thus pg_dump.  
That can be fixed of course, but there might be more programs that use a
similar simple-minded mechanism to check whether quoting is needed.

Also, an empty identifier might be more likely to be a client program bug
than really intended, especially in languages that handle variables
loosely.

OTOH, I'd suggest that we do not enforce the 128 maximum length mandated
by SQL. :-)

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Next question is do we want to change it?  I can't imagine any real good
>> use for a null-string name, but is there any risk of breaking existing
>> applications?

> I think the larger risk is breaking applications if we leave it this way.  

[... cogitates ...]  Yeah, you're probably right.  I agree with changing
it --- any other objectors out there?

> OTOH, I'd suggest that we do not enforce the 128 maximum length mandated
> by SQL. :-)

Check.  Not that I want to set NAMEDATALEN to 129, mind you ... but
I feel that *silent* truncation of overlength identifiers is good
programming language style.  At the moment I seem to be outvoted:

regression=# create table z1234567890123456789012345678901234567890 (f1 int);
NOTICE:  identifier "z1234567890123456789012345678901234567890" will be truncated to "z123456789012345678901234567890"
CREATE

but I will vote to remove that notice if it comes to a vote again.
        regards, tom lane