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
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
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
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
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
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
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
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
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
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
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
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
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
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';
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
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 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 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
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 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
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
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
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
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
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
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
32 matches
Mail list logo
