Re: pg_restore WAS Re: [BUGS] BUG #13702: pg_dump interprets “=” in a db name incorrectly

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Felipe Gasper <felipe(at)felipegasper(dot)com>
Cc: David Gould <daveg(at)sonic(dot)net>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pg_restore WAS Re: [BUGS] BUG #13702: pg_dump interprets “=” in a db name incorrectly
Date: 2015-10-23 19:14:35
Message-ID: CAKFQuwavhkv3pjGx_H1g601siVMtZibt=mdAu+JQyPWmCXGbAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Oct 23, 2015 at 2:54 PM, Felipe Gasper <felipe(at)felipegasper(dot)com>
wrote:

> On 23 Oct 2015 1:33 PM, David G. Johnston wrote:
>
>> On Fri, Oct 23, 2015 at 2:20 PM, Felipe Gasper <felipe(at)felipegasper(dot)com
>> <mailto:felipe(at)felipegasper(dot)com>>wrote:
>>
>
>
>> Again, the "--dbname" argument can either be an actual database name or
>> a "connection info" object.
>>
>
> But the documentation doesn’t say that; it only says that it’s the name of
> the database. Should the documentation be updated, then?
>
> In the later case the "=" has a special
>> meaning. If your database has an "=" in its name then it seems like you
>> have to use the "connection info" definition form. Note I haven't dug
>> into this with respect to pg_restore but that is the findings from the
>> brief psql test I performed.
>>
>
> Is “connection info” an option with pg_restore, though, which mandates a
> --dbname argument?
>
>

http://www.postgresql.org/docs/9.4/interactive/libpq-connect.html#LIBPQ-CONNECT-DBNAME

dbname
The database name. Defaults to be the same as the user name. In certain
contexts, the value is checked for extended formats; see Section 31.1.1 for
more details on those.

​31.1.1
http://www.postgresql.org/docs/9.4/interactive/libpq-connect.html#LIBPQ-CONNSTRING

​See "dbname" in particular

So it is documented.​ Suggestions and patches welcomed if you think it
should be covered differently.

> Here is the execve from strace:
>
> ------------
> [pid 21172] execve("/usr/local/pgsql/bin/pg_restore",
> ["/usr/local/pgsql/bin/pg_restore", "--username=postgres",
> "--host=/tmp/TMP.work.mVasksDJkt0CEJJh/socket", "--no-privileges",
> "--no-owner", "-d", "weird alpha_0123~-_=+[{]}\\\\;:,<.>?",
> "--single-transaction", "--role", "weird alpha_0123~-_=+[{]}\\\\;:,<.>?"],
> [/* 8 vars */]) = 0
> ------------
>
> It spits out the following on STDERR:
>
> -------------
> [archiver (db)] connection to database "" failed: missing "=" after
> "weird" in connection info string
> -------------
>
> It makes sense that the “=” would be interpreted as a special character in
> pg_dump when there is no --dbname parameter. But the docs say that --dbname
> is for a database name; there is no mention of any kind of parsing
> otherwise. Should it not work that way? What purpose is served by passing
> configuration parameters in the database name?
>

​At this point "purpose" doesn't really enter into it. That is how it was
decided things would work and we have to live with it.​ As your particular
situation makes perfectly even if we were to design a better API it
wouldn't apply retroactively. So while fixes for found issues in the
current architecture are welcomed there is likely zero interest in
improving an architecture that while probably imperfect is at least
functional.

> This does work with 9.4 when I use the “postgres:///…” syntax; however, as
> we’re stuck supporting older PgSQLs for the time being (*sigh* even back to
> 8.1), and as PGDATABASE doesn’t work with pg_restore, are we left with
> having to prohibit “=” in database names?

​pg_restore --dbname="dbname=crazy=db=name" [...] likely will work but I
cannot quickly test it ATM.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Felipe Gasper 2015-10-23 19:42:32 Re: pg_restore WAS Re: BUG #13702: pg_dump interprets “=” in a db name incorrectly
Previous Message Felipe Gasper 2015-10-23 18:54:41 Re: pg_restore WAS Re: BUG #13702: pg_dump interprets “=” in a db name incorrectly