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/s...q-connect.html

The passed string can be empty to use all default parameters, or it can
contain one or more parameter settings separated by whitespace. Each
parameter setting is in the form keyword = value. Spaces around the
equal sign are optional. To write an empty value or a value containing
spaces, surround it with single quotes, e.g., keyword = 'a value'.
Single quotes and backslashes within the value must be escaped with a
backslash, i.e., \' and \\.


---------------------------------------------------------------------------

Andrew Dunstan wrote:
> Andrew Dunstan wrote:
> > Tom Lane wrote:
> >> "Andrew Dunstan" <andrew@dunslane.net> 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 proposal is about is migrating from separated
> >> dbname/user/host/port/etc parameters to a unified conninfo parameter.
> >> That seems to me like a good long-term objective, and so I'm willing
> >> to break a few eggs on the way to the omelet, as long as we're not
> >> breaking any very likely usages.
> >>
> >> So: who here has a database with "=" in the name? And hands up if
> >> you've got a database whose name begins with "conn:"?
> >>
> >> I'm betting zero response rate on both of those, so see no reason to
> >> contort the long-term definition for a very marginal difference in
> >> the extent of backwards compatibility ...
> >>
> >>
> >>
> >
> > I'm not sure -hackers is the most representative group to poll regarding
> > dbnames in use ...
> >
> > Anyway, if I understand your current position, the only change needed to
> > my current patch would be that if we fail to parse a dbname parameter
> > that contains an = we simply fail at that point, rather than retrying it
> > as a straight database name.
> >
> > I'm OK with that.
> >
>
>
> Here's the patch for what I think is the consensus position. If there's no
> objection I will apply this and document it.
>
> cheers
>
> andrew

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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 the patch need documentation too? Are we
deprecating the psql options now duplicated by the new functionality,
like host/port/username/password?

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Bruce Momjian <bruce@momjian.us> 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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 options now duplicated by the new functionality,
>> like host/port/username/password?
>>
>
> I'd vote not. This is just another way to do it.
>
>
>

I entirely agree. It lets you do some nice things that aren't obvious
now, like:

psql 'service=foo sslmode=require'

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq