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
On Fri, Dec 9, 2011 at 6:03 AM, Alexander Shulgin a...@commandprompt.com
wrote:
See above. The hope is that URIs will be compatible sans the driver-specific
extra query parameters which might be not recognized by either party.
Yeah. I am not that concerned with being stupidity-compatible
On Fri, Dec 9, 2011 at 3:03 AM, Alexander Shulgin a...@commandprompt.com
wrote:
The JDBC driver is special in that it intentionally does not use libpq.
Given every other binding (think Ruby, Python, Perl, Tcl, etc.) does use
libpq, it makes perfect sense to me to make the syntax compatible
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
On Tue, Nov 29, 2011 at 12:02 PM, Alexander Shulgin
a...@commandprompt.com wrote:
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
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,
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
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 is how CUPS handles this problem
when connecting printers using URIs:
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
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,
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
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
On Nov 24, 2011, at 9:40 AM, Martijn van Oosterhout wrote:
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, the UNIX domain socket
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
On Nov 24, 2011, at 1:57 AM, Alexander Shulgin a...@commandprompt.com wrote:
While it is really tempting to provide support for all that fancy stuff (or
at least support user:password@host part instead of the ugly
?user=password=) this will make psql URIs backward-incompatible with the
JDBC
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
Excerpts from Alexander Shulgin's message of jue nov 24 05:58:57 -0300 2011:
Excerpts from Martijn van Oosterhout's message of Thu Nov 24 09:40:42 +0200
2011:
Which does raise the valid question of how to represent that in URI
syntax. SQLAlchemy (for example) doesn't try with it's URL
On Thu, Nov 24, 2011 at 7:33 AM, Alexander Shulgin
a...@commandprompt.com wrote:
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
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?
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.
Excerpts from Robert Haas's message of jue nov 24 10:35:36 -0300 2011:
On Thu, Nov 24, 2011 at 7:33 AM, Alexander Shulgin
a...@commandprompt.com wrote:
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
Excerpts from Martijn van Oosterhout's message of jue nov 24 04:40:42 -0300
2011:
How about the service option, that's a nice way of handling
non-default socket options.
What about it? Are you suggesting we should support some way to specify
a service name in the URI?
If so, consider this:
On Thu, Nov 24, 2011 at 8:50 AM, Alexander Shulgin
a...@commandprompt.com wrote:
What JDBC supports is rather weird and far from being ideal:
http://jdbc.postgresql.org/documentation/head/connect.html
The problem with supporting multiple syntaxes, IMO is that it makes libpq
compatible in
Excerpts from Alvaro Herrera's message of jue nov 24 10:21:49 -0300 2011:
A coworker also suggested using a different designator:
postgresqli:///path/to/socket:5433/database
postgresqli://:5433/database
I forgot to mention: this i thing comes from LDAP. Apparently you can
use ldapi:// to
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
On Thu, Nov 24, 2011 at 8:54 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Martijn van Oosterhout's message of jue nov 24 04:40:42 -0300
2011:
How about the service option, that's a nice way of handling
non-default socket options.
What about it? Are you suggesting we
* Alvaro Herrera:
I think we should just propose something that will not work in JDBC.
I'm not sure if this is a good idea. 8-)
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
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:
Excerpts from Florian Weimer's message of jue nov 24 11:31:29 -0300 2011:
* Alvaro Herrera:
I think we should just propose something that will not work in JDBC.
I'm not sure if this is a good idea. 8-)
I plan to add UNIX Domain socket support to the JDBC driver.
Eventually, the JDK
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
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
* Alvaro Herrera:
Excerpts from Florian Weimer's message of jue nov 24 11:31:29 -0300 2011:
* Alvaro Herrera:
I think we should just propose something that will not work in JDBC.
I'm not sure if this is a good idea. 8-)
I plan to add UNIX Domain socket support to the JDBC driver.
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 the whole thing would look like this:
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
On tor, 2011-11-24 at 09:02 -0500, Robert Haas wrote:
e.g. if we used the format suggested in my previous email, this would
just boil down to:
postgresql:///?service=foo
More correct would be
postgresql:?service=foo
See http://en.wikipedia.org/wiki/URI_scheme for some inspiration.
--
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, no?
What would you do with such URI if you need to other people to connect
to
It was proposed a while ago for libpq to support URI syntax for specifying
the connection information:
...
Now we're going to actually implement this.
Do you know that we had this feature (more or less) in libpq for years but it
was removed quite a while ago. It should still be there in the
* 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://example.net:5433/mydb
How would you specifiy a local port/UNIX domain socket?
Would
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
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
Hey Alexander,
2011/11/24 Alexander Shulgin a...@commandprompt.com
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
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
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, the UNIX domain socket would be
considered by libpq just as if you would pass -h
2011/11/24 Alexander Shulgin a...@commandprompt.com
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
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
45 matches
Mail list logo
