Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
OK, good to know. Does the patch need documentation too?
Certainly.
That's why I haven't committed it yet. I intend to put info in the psql
manual as well as in the libpq reference.
Are we
deprecating the psql opti
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, good to know. Does the patch need documentation too?
Certainly.
> Are we
> deprecating the psql options now duplicated by the new functionality,
> like host/port/username/password?
I'd vote not. This is just another way to do it.
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> >
> > I assume this patch will still allow a database name with an equals
> > sign, right?
> >
> >
> > psql "dbname='a=b'"
>
>
> Yes. In fact, reading the code it looks like the quotes are not necessary
> in this case.
OK, good to know. Does th
Bruce Momjian wrote:
>
> I assume this patch will still allow a database name with an equals
> sign, right?
>
>
> psql "dbname='a=b'"
Yes. In fact, reading the code it looks like the quotes are not necessary
in this case.
cheers
andrew
---(end of broadcast)--
I assume this patch will still allow a database name with an equals
sign, right?
psql "dbname='a=b'"
The libpq documentation isn't clear that single-quotes also escape
equals, but I assume that is true looking at the code:
http://www.postgresql.org/docs/8.2/static/libpq-connec
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> BTW, what is the approved way to handle warnings about const? Copy the
> object?
Well, in the revised code there shouldn't be any warning at all, but
I think the mistake in your original was to declare the local variable
as "char *" instead of "const
Andrew Dunstan wrote:
> Tom Lane wrote:
>> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>>
>>> We change libpq from time to time. Besides, how many DBs are there that
>>> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
>>> expect lots of surprise.
>>>
>>
>> Um, but how many
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
We change libpq from time to time. Besides, how many DBs are there that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
expect lots of surprise.
Um, but how many DB names have an "=" in them at all?
B
Tom Lane wrote:
>> We change libpq from time to time. Besides, how many DBs are there
that
>> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I
don't
>> expect lots of surprise.
>
> Um, but how many DB names have an "=" in them at all?
>
> Basically what this proposal is about is
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> We change libpq from time to time. Besides, how many DBs are there that
> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
> expect lots of surprise.
Um, but how many DB names have an "=" in them at all?
Basically what this pro
Casey Duncan wrote:
>
> I was speaking from and end-user point of view, but I see your point.
> It's certainly attractive to just patch libpq and be done. However,
> that does have the side-effect of implicitly propagating the behavior
> to all libpg client software. That may be more unpleasantly
On Dec 12, 2006, at 5:16 PM, Andrew Dunstan wrote:
Casey Duncan wrote:
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd ge
Casey Duncan wrote:
> On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
>
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> Right. Here's the patch I just knocked up, which seems to Just
>>> Work (tm) ;-)
>>
>> The main objection I can see to this is that you'd get a fairly
>> unhelpful message if you i
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there w
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Right. Here's the patch I just knocked up, which seems to Just Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there was
anything wrong with your syntax (eg, misspelle
Tom Lane wrote:
Martijn van Oosterhout writes:
Does that mean that:
psql -d "service=myservice"
should Just Work(tm)? That would be nice.
Even more to the point,
psql "service=myservice"
which is why we want to overload dbname rather than any of the other
PQsetdbLogin parame
Martijn van Oosterhout writes:
> Does that mean that:
> psql -d "service=myservice"
> should Just Work(tm)? That would be nice.
Even more to the point,
psql "service=myservice"
which is why we want to overload dbname rather than any of the other
PQsetdbLogin parameters for this --- dbna
On Tue, Dec 12, 2006 at 05:44:07PM -0500, Andrew Dunstan wrote:
> Now I look at fe-connect.c more closely, I'm tempted just to try parsing
> the dbname param as a conninfo string, and if it doesn't work fall back
> on a plain dbname. I could greatly reduce the chance of following the
> failure p
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql "conn:service=sname user=uname"
Perhaps this should be implemented in libpq, not at the p
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have been working on providing psql with the ability to accept a libpq
> conninfo string, so that the following now works for me:
> psql "conn:service=sname user=uname"
Perhaps this should be implemented in libpq, not at the psql level?
Otherwise y
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql "conn:service=sname user=uname"
Instead of providing yet another switch, I overloaded the dbname
parameter so that if it has the recognised prefix the rema
21 matches
Mail list logo
