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 c
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 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 (pgsq
Peter Eisentraut 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 into sr
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'
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 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" ou
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
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'
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
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'
* 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 a
Florian Weimer 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 postgres:///path/to/differen
* 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
Greg Smith 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.
OK, I've used the c
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 t
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
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
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 tar
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 UR
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
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
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
> nickname for the project, and is eminently more pronounceable. Once
> the url is establis
On Mon, Dec 12, 2011 at 5:05 PM, David E. Wheeler 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
"Everything was
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
On Mon, Dec 12, 2011 at 2:06 PM, Alexander Shulgin
wrote:
>
>
> psql -d postgresql://user@pw:host:port/dbname?param1=value1¶m2=value2...
>
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 th
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
27 matches
Mail list logo
