From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | Mike Toews <mwtoews(at)gmail(dot)com> |
Cc: | pgsql-docs(at)postgresql(dot)org |
Subject: | Re: pg_dump -t '"Table"' for cmd.exe |
Date: | 2012-11-14 03:49:12 |
Message-ID: | CAK3UJRHi90DyuS0dUGMRf68fov82QB5Mb650kkms0eGzDd3e5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Mon, Nov 12, 2012 at 8:45 PM, Mike Toews <mwtoews(at)gmail(dot)com> wrote:
> I'm not sure if this is worth documenting, but pg_dumping mixed-case tables
> with the '-t table' option appears to not be accurately documented for
> cmd.exe. Here are my four attempts, with only the last as success:
I believe this complaint is basically the same as this recent one:
http://archives.postgresql.org/pgsql-bugs/2012-10/msg00044.php
and this behavior confused me recently as well. I agree the behavior
should be documented, though it should be documented for all our
utilities which accept a --table argument and pass it on as a
supposedly already-escaped identifier.
Incidentally, I'm really not fond of the existing behavior because it:
a.) is counterintuitive
b.) requires the user to escape table names themselves, and how were
they even supposed to have a chance of programmatically doing this
properly before we exposed PQescapeIdentifier()
c.) opens possible SQL injection holes, e.g.
reindexdb --table='foo; ALTER ROLE limited WITH superuser'
Josh
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Kupershmidt | 2012-11-14 04:23:13 | Re: Incomplete compatibility information for triggers |
Previous Message | Craig Ringer | 2012-11-14 00:10:27 | Re: Add contrib module functions to docs' function index |