Issue status update for http://drupal.org/node/26836 Post a follow up: http://drupal.org/project/comments/add/26836 Project: Drupal -Version: 4.6.2 +Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: iamtheari Updated by: Cvbge -Status: patch (code needs review) +Status: patch (code needs work) And topic change. Cvbge Previous comments: ------------------------------------------------------------------------ Sat, 16 Jul 2005 16:52:16 +0000 : iamtheari Attachment: http://drupal.org/files/issues/drupal-pgsql-socket.patch (917 bytes) Drupal does not allow for PostgreSQL connections via unix socket. I have written a patch that allows it to do so. The effect of this patch is that a hostname of 'localhost' in a pgsql:// $db_url will use Unix sockets unless a port it set in the URL. A hostname of '127.0.0.1' will use TCP/IP as before. Examples: Unix socket: pgsql://user:pass@localhost/db TCP/IP: pgsql://user:pass@localhost:4444/db TCP/IP: pgsql://user:pass@127.0.0.1/db TCP/IP: pgsql://user:pass@127.0.0.1:4444/db The patch is attached to this bug report. From a top-level Drupal directory, type 'patch -p0 < /path/to/drupal-pgsql-socket.patch' to apply it (omit the single-quotes). ------------------------------------------------------------------------ Sat, 16 Jul 2005 17:08:09 +0000 : chx First, welcome among contributors and thanks for the patch, it looks useful. There are a few general problems: only bugfixes go into 4.6.x everything else, like this should be for HEAD. Other problem is with coding style, we use <?php if () { } else { } ?> also you spacing issues, like spaces are a dot. The rule, as explained to me by Steven is that there is never a space between a dot and a quote always otherwise. There is also coding style guideline in CVS. ------------------------------------------------------------------------ Sun, 17 Jul 2005 05:06:39 +0000 : iamtheari I don't run the CVS version, but somehow I doubt that the file in question has changed significantly enough to prevent the patch from working. As to the coding style, see now that Drupal's guidelines require the space between "if" and "(", but the extra spaces around the dots was from the original code in the patched file, as you can see from the lines of the patch beginning with a "-". Regardless, I hope that my code can be hammered into shape so as to fit into Drupal. Just be sure to warn people that the behavior of 'pgsql://user:password@localhost/db' has changed, if this makes it in. ------------------------------------------------------------------------ Mon, 25 Jul 2005 17:32:51 +0000 : Steven Are Unix sockets something that is standard supported and enabled for PGSQL? If not, it is confusing to change the behaviour just because you enter "localhost" with no port. Why not make a special reserved hostname (e.g. 'unixsocket') for this? It can be documented easily in settings.php. ------------------------------------------------------------------------ Wed, 27 Jul 2005 20:12:07 +0000 : Cvbge AFAIK sockets are supported by both mysql and postgres... but I think they might not allways be accessible (well, the same can be said about tcp connections). I also think that we should not break existing configurations and use other syntax for specifying. Also you might need to provide path to unix socket. ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:07:38 +0000 : iamtheari Postgres almost prefers Unix socket connections to TCP/IP. It is easier to set up working Unix sockets than TCP/IP connections with Postgres. The PHP pg_connect() function's connection string will connect via Unix socket if the "host=" element is omitted. That is how my patch works, but Drupal's means of handling the database URL prevented a blank hostname from being accepted. Also, using a made-up hostname to signify a Unix socket is kludgy, at best. Note that no path needs to be specified. The way PHP connects via Unix socket is to use the local Postgres libraries, and it seems to find the socket just fine if it exists. ------------------------------------------------------------------------ Fri, 05 Aug 2005 00:29:17 +0000 : Steven I still think we should go for the "made up name" path. It means there is no hidden switch between unix socket and tcp/ip just because you remove the port number for example. We get enough support questions about configuration already. Let's just document the magic socket host name (I'd go for 'socket' for simplicity) and do it that way. ------------------------------------------------------------------------ Fri, 05 Aug 2005 09:01:04 +0000 : Cvbge I've just checked php documentation. It seems pg_connect() do not have socket-path argument :( OTOH mysql_connect() accepts socket path (you can put it in place of port number). [mysql is weird anyway because it will try to connect using sockets when you use 'localhost' as a server name, even if you specify normal tcp/ip port number...] I think that if we are going to support sockets officially we should support socket paths as well! So the next question is about string syntax. I think it was wrong to use dbtype://user:pass@host:port/dbname syntax. Clearer, simpler, easier to modify would be some sort of hash, like 'dbtype' => 'postgresql', 'username' => 'blah', 'password' => 'foo', etc. But it's too late to change it now, right? So, we have to go with current syntax. I'm not sure what would be the best solution. But, about the It means there is no hidden switch between unix socket and tcp/ip just because you remove the port number for example.. I don't see how removing port number would make the switch? Adding socket path support is kludgy. It's because of slashes in the path which collide with /dbname... I really don't know how to solve this problem, but I belive it needs to be solved. If it can't be solved using current syntax maybe we should go for array syntax as an alternative syntax? ------------------------------------------------------------------------ Mon, 08 Aug 2005 22:57:20 +0000 : iamtheari I guess I wouldn't complain about 'socket' being the magic name, as long as it's clearly and obviously documented. It took me enough time to find out that PG sockets weren't supported in the first place, reading through the documentation carefully. As to socket paths, if pg_connect() doesn't support them then I don't see either an obvious way to implement them or an obvious reason to do so. It would be nice to be consistent and complete, yes, but if the underlying software doesn't support it then there's no real need to waste our time with it, either. It obviously works well enough for all the PHP/Postgres developers of the world. ------------------------------------------------------------------------ Tue, 09 Aug 2005 07:26:44 +0000 : Cvbge "As to socket paths, if pg_connect() doesn't support them then I don't see either an obvious way to implement them or an obvious reason to do so. It would be nice to be consistent and complete, yes, but if the underlying software doesn't support it then there's no real need to waste our time with it, either. " mysql_connect() supports socket path. ------------------------------------------------------------------------ Tue, 09 Aug 2005 15:37:23 +0000 : iamtheari Why exactly are mysql_connect()'s capabilities relevant? ------------------------------------------------------------------------ Fri, 12 Aug 2005 19:51:38 +0000 : Cvbge Are they now enough relevant?