pgsql - pg_connect string in install.pgsql.inc fails to connect on blank password

MySQL allows connection without password, so it makes sense pgsql would as well.

I've discovered the same problem, I wrote a patch, and was going to file a bug, but found this one (with an almost identical patch).

Is there any plan to put this patch into version control?

I tested it using Postgres 8.1, PHP5 in a Linux VServer

The use of isset() looks inconsistent. Care to double-check that?

Strange. Why couldn't the port number be an empty string? Why would $port be different from $pass? Is that a weirdity in PHP's parse_url()? It would be appreciated if we could investigate this a bit more.

I think this is only a partial solution. The "standard" way to connect to a postgresql database running on the current host is to simply do
pg_connect("user=dbuser dbname=databasename") which will use the default access method, which is usually to connect to the Unix Domain Socket which supports reliable identfication (no silly passwords).

The problem with this "parse the url approach" is that I can't produce such a conn-string, nor can I produce a conn-string that looks like "host=/var/run/postgresql user=dbuser dbname=databasename" (which would also work) since the slashes messes things up.

So, I ended up doing the following:
In my settings.php:
$db_url = "pgsql://user=dbuser dbname=databasename";

And patching database.pgsql.inc to say:
$connection = @pg_connect(urldecode($url['host']));

This solves all problems for me since it doesn't try to be intelligent and thus destroy things.

In order to solve all these kinds of problems I would suggest implementing a simple check to see if the host-string from parse_url contains the string "user=" and if that's the case pass it through unmodified to pg_connect. Or provide an example of how to do this.

Requiring the use of connecting to localhost, passwords, etc is just silly when there has been a good method of connecting to the postgresql server for quite some time now. The installation instructions should be updated to reflect this (connecting to localhost instead of the unix domain socket is almost always wrong).

When I set up my Drupal application (version 5.1) as the first user and connect with a database (postgres) with an empty password. I got an error "Cannot connect to database .... check username, password...". Apply this path, my problem is solved.
Great job.

It would fix many problems if we'd just get rid of the URL and use individual variables as proposed by Shiny.

an empty password also throws 2 "undefined index" php notices with mysql:

PHP Notice:  Undefined index:  pass in includes\install.mysql.inc on line 32
PHP Notice:  Undefined index:  pass in install.php on line 148

(CVS HEAD of today, 31-Aug-2007). this would be fixed with individual variables as suggested in #13.

Shiny - are you still listening? i think Dries approved - now will you make another patch? :) a big thank you from me in advance!

Shiny: great - looking forward to see this going into Drupal!

Subscribing. I posted a fix a long time ago for pg_connect at http://drupal.org/node/18586 (explanation is at http://drupal.org/files/issues/debian-bug-295496) to allow connecting to postgresql using unix sockets. There is also recent discussion at http://drupal.org/node/26836 about Socket Connection/path support.

Double check with latest CVS HEAD and found the problem still existing in install.pgsql.inc. This patch backport the handling from current db_connect(), which employ the original bug fix idea. Patch tested for PostgreSQL 8.1.9 on Debian etch 4.0r1 with PHP 5.2.0-8+etch7. Installation is passed with no error message. Should be trivial to commit.

Looks good here.

would it be possible to solve this with the more elegant solution proposed by shiny in http://drupal.org/node/125105#comment-229460 ? no urldecode()s, less code, a +1 from dries (and me) ... tnx!

@ax: that sounds good for me too, but should be another issue. At least my patch is just reusing the current implementation, which should be always correct. Since D6 beta2 is already out, I am really hoping to help about the complete of pgsql implementation, with as less problem as possibile. At least, we should fix this critical bug on time with a simple approach. Just let this in, and further more explore for other possibility?

Moreover, according to my previous research with Oracle/DB2/MSSQL, our current syntax can also works fine with it. I would like to support either: 1) change all database handling as new array style (require for more time and patch with more test), or 2) keep existing syntax plus this patch, but not 3) introduce different syntax between databases (a bit confusing...). Any idea?

ax: migrating to a different method for database settings in settings.php is a big change which we are not going to do after Drupal 6.0 beta 2. Although Dries said it is a better solution, that was in April, and there was no patch to migrate to that model when Drupal 6 was open for such changes. Now we are fixing bugs, which hswong3i's patch does exacly. So committed that one.

Feel free to open an issue against Drupal 7 to migrate to an array format for database settings, if you'd like.

Thanks Gabor :)

Follow up: I just open another issue for Shiny's suggestion (http://drupal.org/node/184917). Maybe we have chance to ship it with D6, maybe we don't but need to wait for D7, I don't really know. BTW, it is a good idea that we should give some love about :)