Re: [HACKERS] WIP: URI connection string support for libpq

2012-02-25 Thread Alexander Shulgin
On 02/25/2012 09:37 PM, Cédric Villemain wrote: I've not followed all the mails about this feature but I don't find it is a nice syntax too. ?dbname=other looks like dbname is an argument, but dbname is a requirement for postgresql connexion. Ugh, not really. AFAIK, dbname is a connection

Re: [HACKERS] WIP: URI connection string support for libpq

2012-02-28 Thread Alexander Shulgin
On 02/24/2012 03:18 PM, Florian Weimer wrote: * Alex Shulgin: It's ugly, but it's standard practice, and seems better than a separate -d parameter (which sort of defeats the purpose of URIs). Hm, do you see anything what's wrong with ?dbname=other if you don't like a separate -d? It's not

Re: [HACKERS] WIP: URI connection string support for libpq

2012-03-06 Thread Alexander Shulgin
On 03/06/2012 01:09 AM, Peter Eisentraut wrote: On ons, 2012-02-22 at 12:26 -0500, Greg Smith wrote: I started collecting up all the variants that do work as an initial shell script regression test, so that changes don't break something that already works. Here are all the variations that

Re: [HACKERS] WIP: URI connection string support for libpq

2012-03-07 Thread Alexander Shulgin
On 03/07/2012 08:03 PM, Peter Eisentraut wrote: On ons, 2012-03-07 at 18:31 +0200, Alex Shulgin wrote: I figured that adding this right into src/interfaces/libpq is polluting the source dir, so I've used src/test instead. I would prefer src/interfaces/libpq/test, to keep it close to the

Re: [HACKERS] WIP: URI connection string support for libpq

2012-03-07 Thread Alexander Shulgin
On 03/07/2012 09:16 PM, Alexander Shulgin wrote: I would prefer src/interfaces/libpq/test, to keep it close to the code. Hm, actually that makes more sense and is not unprecedented (I see ecpg has it's own 'test' subdir.) Apparently I was under false impression that all regression tests

[HACKERS] Postmaster holding unlinked files for pg_largeobject table

2011-06-03 Thread Alexander Shulgin
Hello Hackers, There is some strange behavior we're experiencing with one of the customer's DBs (8.4) We've noticed that free disk space went down heavily on a system, and after a short analysis determined that the reason was that postmaster was holding lots of unlinked files open. A sample

[HACKERS] Notes on implementing URI syntax for libpq

2011-11-21 Thread Alexander Shulgin
Hello, It was proposed a while ago for libpq to support URI syntax for specifying the connection information: http://archives.postgresql.org/message-id/1302114698.23164.17.camel@jd-desktop http://archives.postgresql.org/pgsql-hackers/2011-07/msg01144.php It appears to me that the

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-23 Thread Alexander Shulgin
Excerpts from Florian Weimer's message of Wed Nov 23 13:04:47 +0200 2011: * Alexander Shulgin: This, in my opinion, is very similar to what we would like to achieve with the URI syntax, so the above could also be specified using a URI parameter like this: psql -d postgresql

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-23 Thread Alexander Shulgin
Excerpts from Florian Weimer's message of Wed Nov 23 13:04:47 +0200 2011: * Alexander Shulgin: This, in my opinion, is very similar to what we would like to achieve with the URI syntax, so the above could also be specified using a URI parameter like this: psql -d postgresql

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-23 Thread Alexander Shulgin
Excerpts from Dmitriy Igrishin's message of Thu Nov 24 09:19:02 +0200 2011: If host part of the URI points to localhost, the UNIX domain socket would be considered by libpq just as if you would pass -h localhost -p 5433. But what if the user wants to connect exactly via socket or TCP/IP

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Martijn van Oosterhout's message of Thu Nov 24 09:40:42 +0200 2011: On Thu, Nov 24, 2011 at 08:59:56AM +0200, Alexander Shulgin wrote: How would you specifiy a local port/UNIX domain socket? Missed that in my previous reply. If host part of the URI points to localhost

Re: [HACKERS] Making TEXT NUL-transparent

2011-11-24 Thread Alexander Shulgin
Excerpts from Florian Weimer's message of Thu Nov 24 11:27:51 +0200 2011: and why you don't use bytea ? Text should be correct literal. It's actually UTF-8 text, and some PostgreSQL functions are only available for TEXT, but not BYTEA, e.g.: bfk_int= SELECT '\x006500'::bytea ~ 'A';

Re: [HACKERS] Making TEXT NUL-transparent

2011-11-24 Thread Alexander Shulgin
Excerpts from Florian Weimer's message of Thu Nov 24 12:59:09 +0200 2011: I have a different question. What is reason for embedded NULs inside strings? The source system does not enforce that constraint, so from time to time, such data slips through. I don't know why it's there in the

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Thu Nov 24 13:57:17 +0200 2011: I think it would be really weird not to support user:pw@host:port. You can presumably also support the JDBC style for backward compatibility, but I don't think we should adopt that syntax as project standard. Well, I

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Alvaro Herrera's message of Thu Nov 24 15:21:49 +0200 2011: I think the question is allowing the URI to specify a service. Huh? The service definitions are read from a local pg_service.conf, and are specified by setting PGSERVICE (and PGSERVICEFILE) environment variables, no?

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Thu Nov 24 15:35:36 +0200 2011: Do you suggest that we should reconsider? I guess my feeling is that if we're going to have URLs, we ought to try to adhere to the same conventions that are used for pretty much every other service that supports URLs.

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Thu Nov 24 15:59:08 +0200 2011: Well, based on that document, I think that trying to be bug-compatible with the JDBC syntax is a, erm, doomed effort. I mean, what are you going to do with things like loglevel or logUnclosedConnections that change the

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Alexey Klyukin's message of Thu Nov 24 10:22:21 +0200 2011: Another idea is to use local:/dir/name for UNIX domain socket instead of hostname:port, like it's displayed in the psql prompt. So the whole thing would look like this:

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Thu Nov 24 16:02:38 +0200 2011: So, in that light, do we still think that letting the user specify a service name in the URI makes sense?  (My personal opinion is yes). service is just a connection parameter, so if we choose a URL format that

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Florian Weimer's message of Thu Nov 24 16:31:29 +0200 2011: I plan to add UNIX Domain socket support to the JDBC driver. Eventually, the JDK will expose UNIX Domain sockets to Java code, too (they are already used internally for management functions). Do you maybe plan to

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-24 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Thu Nov 24 17:02:13 +0200 2011: On Thu, Nov 24, 2011 at 9:40 AM, Alexander Shulgin a...@commandprompt.com wrote: Another idea is to use local:/dir/name for UNIX domain socket instead of hostname:port, like it's displayed in the psql prompt. So

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-26 Thread Alexander Shulgin
Excerpts from Peter Eisentraut's message of Thu Nov 24 22:05:09 +0200 2011: On tor, 2011-11-24 at 15:43 +0200, Alexander Shulgin wrote: Huh? The service definitions are read from a local pg_service.conf, and are specified by setting PGSERVICE (and PGSERVICEFILE) environment variables

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-26 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Thu Nov 24 15:59:08 +0200 2011: I think we could do something like: postgresql://user:pw@host:port/database?param1=val1param2=val2param3=val3... I wonder if this should be allowed syntax (i.e. specify a user, but connect locally, so leave 'host' to

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-26 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Thu Nov 24 13:57:17 +0200 2011: I think it would be really weird not to support user:pw@host:port. You can presumably also support the JDBC style for backward compatibility, but I don't think we should adopt that syntax as project standard. By the

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-28 Thread Alexander Shulgin
Excerpts from Greg Smith's message of Mon Nov 28 10:08:42 +0200 2011: On 11/24/2011 05:21 AM, Alvaro Herrera wrote: A coworker also suggested using a different designator: postgresqli:///path/to/socket:5433/database postgresqli://:5433/database This is not unprecedented. An example

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-29 Thread Alexander Shulgin
Excerpts from Alexander Shulgin's message of Sat Nov 26 21:46:32 +0200 2011: I would also think that if one is to specify the password in the URI, and the password happen to contain the @-sign (e.g. !@#$%^,) it should be percent-encoded, like: postgresql://user:!%40#$%^@/ Actually,

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-11-29 Thread Alexander Shulgin
Excerpts from Alexander Shulgin's message of Sat Nov 26 22:07:21 +0200 2011: So how about this: postgresql:ssl://user:pw@host:port/dbname?sslmode=... The postgresql:ssl:// designator would assume sslmode=require, if not overriden in extra parameters and postgresql:// would imply

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-12-09 Thread Alexander Shulgin
Excerpts from Daniel Farina's message of Mon Dec 05 11:56:19 +0200 2011: I think the current direction is fine, although as Robert Haas has said, I am not really at all inclined to view JDBC compatibility as any kind of a plus. JDBC URLs are weird, and do the drivers actually link libpq

Re: [HACKERS] Notes on implementing URI syntax for libpq

2011-12-09 Thread Alexander Shulgin
Excerpts from Daniel Farina's message of Fri Dec 09 23:04:26 +0200 2011: I guess if I move the parenthetical grouping of logic around, what you are probably intending to say is everyone except this one ecosystem does the normal thing, so we have an opportunity to Unite The Clans, by

[HACKERS] WIP: URI connection string support for libpq

2011-12-12 Thread Alexander Shulgin
Hello Hackers, Attached is a work-in-progress patch for URI connection string syntax support in libpq. The recent discussion (also pointing to the original one) is here: http://archives.postgresql.org/message-id/132180-sup-1235@moon The patch adds support for the following syntax in

Re: [HACKERS] WIP: URI connection string support for libpq

2011-12-13 Thread Alexander Shulgin
Excerpts from Robert Haas's message of Tue Dec 13 23:31:32 +0200 2011: On Mon, Dec 12, 2011 at 6:55 PM, Peter van Hardenberg p...@pvh.ca wrote: I'd like to make the controversial proposal that the URL prefix should be postgres: instead of postgresql:. Postgres is a widely accepted

Re: [HACKERS] WIP: URI connection string support for libpq

2011-12-14 Thread Alexander Shulgin
Excerpts from Greg Smith's message of Wed Dec 14 02:54:14 +0200 2011: Initial quick review of your patch: you suggested this as the general form: psql -d postgresql://user@pw:host:port/dbname?param1=value1param2=value2... That's presumably supposed to be: psql -d