Peter Eisentraut pete...@gmx.net writes:
I've included a (separate) test shell script based on Greg's cases in
one of the updates. What would be preferred place to plug it in?
Override installcheck in libpq Makefile?
I think that would be the right place.
I figured that adding this right
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.
--
Sent via pgsql-hackers mailing list
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 are
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 tis, 2012-03-06 at 10:11 +0200, Alexander Shulgin wrote:
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
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
already work, setup so that a series of 1 outputs
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
Le vendredi 24 février 2012 14:18:44, Florian Weimer a écrit :
* 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
Le vendredi 24 février 2012 14:18:44, Florian Weimer a écrit :
* 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
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
Greg Smith g...@2ndquadrant.com writes:
Thank you for the review, Greg!
Given that, there really isn't a useful path forward that helps out
all those developers without supporting both prefixes. That's where
this left off before, I just wanted to emphasize how clear that need
seems now.
* Alex Shulgin:
Yeah, this is really appealing, however how do you tell if the part
after the last slash is a socket directory name or a dbname? E.g:
psql postgres:///path/to/different/socket/dir(default dbname)
psql postgres:///path/to/different/socket/dir/other (dbname=other ?)
Florian Weimer fwei...@bfk.de writes:
* Alex Shulgin:
Yeah, this is really appealing, however how do you tell if the part
after the last slash is a socket directory name or a dbname? E.g:
psql postgres:///path/to/different/socket/dir(default dbname)
psql
* 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 nice URI syntax, but it's better than an
This submission has turned into a bit of a mess. I did the closest
thing to a review the day after it was submitted; follow-up review
attempts had issues applying the patch. And it's been stuck there. The
patch is still fine, I just tested it out to pick this back up myself
again. I think
On Tue, Dec 13, 2011 at 07:54:14PM -0500, Greg Smith wrote:
After this bit of tinkering with the code, it feels to me like this
really wants a split() function to break out the two sides of a
string across a delimiter, eating it in the process. Adding the
level of paranoia I'd like around
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
On Mon, Dec 12, 2011 at 5:05 PM, David E. Wheeler da...@justatheory.com wrote:
On Dec 12, 2011, at 3:55 PM, Peter van Hardenberg wrote:
only a nearly insurmountable mailing list thread
prevents it.
What happened to SexQL?
Case in point.
--
Peter van Hardenberg
San Francisco, California
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
nickname for the project, and is eminently more pronounceable. Once
the url is
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
On 12/13/2011 05:45 PM, Alexander Shulgin wrote:
Before that, why don't also accept psql://, pgsql://, postgre://
and anything else? Or wait, aren't we adding to the soup again (or
rather putting the soup right into libpq?)
There are multiple URI samples within PostgreSQL drivers in the
On 12/13/2011 04:54 PM, Greg Smith wrote:
On 12/13/2011 05:45 PM, Alexander Shulgin wrote:
Before that, why don't also accept psql://, pgsql://, postgre://
and anything else? Or wait, aren't we adding to the soup again (or
rather putting the soup right into libpq?)
There are multiple URI
On 12/13/2011 08:11 PM, Joshua D. Drake wrote:
Because the use of Java/JDBC dwarfs both of your examples combined.
Don't get me wrong, I love Python (everyone knows this) but in terms
of where the work is being done it is still in Java for the most part,
by far.
I was talking about better
On Mon, Dec 12, 2011 at 2:06 PM, Alexander Shulgin
a...@commandprompt.com wrote:
psql -d postgresql://user@pw:host:port/dbname?param1=value1param2=value2...
I'd like to make the controversial proposal that the URL prefix should
be postgres: instead of postgresql:. Postgres is a widely
On Dec 12, 2011, at 3: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
nickname for the project, and is eminently more pronounceable. Once
the url is established it will
26 matches
Mail list logo
