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 regre
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 code
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
alr
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 no
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=value1¶m2=value2...
>
> That's presumably supposed to be:
>
> psql -d postgresql://use
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 wrote:
> > I'd like to make the controversial proposal that the URL prefix should
> > be "postgres:" instead of "postgresql:". Postgres is a widely accepted
> > nickna
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 psq
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 ab
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 libp
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://" woul
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#$%^@/
Actua
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.
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 th
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=val1¶m2=val2¶m3=val3&...
I wonder if this should be allowed syntax (i.e. specify a user, but connect
locally, so leave 'host' to be
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 PGS
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
> wrote:
> >> Another idea is to use local:/dir/name for UNIX domain socket instead of
> >> hostname:port, like it's displayed in
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 s
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
> tha
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:
postgresql://local:/dir/name/dbname?param1=
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
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
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 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,
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
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 ~
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.
> >
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 o
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
> &
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
> &
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 consensus
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 o
32 matches
Mail list logo
