public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: Tom Lane <[email protected]>
Cc: Susanne Ebrecht <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Grzegorz Szpetkowski <[email protected]>
Cc: [email protected]
Subject: Re: createuser/dropuser username
Date: Wed, 7 Sep 2011 21:37:28 -0400 (EDT)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > Uh, I did some digging after this email report and found it does need
> > some cleanup, which is done in the attached patch.
> 
> > It removes quoting for table references in clusterdb and index/table
> > references in reindexdb,
> 
> Uh, surely that breaks things.  Or did you miss my statement that the
> current behavior is what is intended?

I saw that, but how is that consistent with other command-line tools? 
What is the logic that has some tools preserve case and others not?

> > and adds a general documentation overview about
> > when case is preserved and suggests quoting, and adds documentation
> > where special quoting happens.
> 
> I don't find the documentation changes to be improvements either.
> Possibly instead of
> 
> > !         Specifies the default tablespace for the database (double-quoted internally).
> 
> you could do something like
> 
>          Specifies the default tablespace for the database.  (This name
>          is not subject to case-folding.)

OK.

> > +    <para>
> > +     When specified on the command line, user and databases names have
> > +     their case preserved &mdash; the presence of spaces or special
> > +     characters might require quoting.  Table names and other identifiers
> > +     do not have their case preserved, except where documented, and
> > +     might require quoting.
> > +    </para>
> 
> This latter sentence is just plain wrong.

Really?  Pg_dump doesn't preserve case for table names:

	pg_dump -t Test test

	$ pg_dump -t Test test
	pg_dump: No matching tables were found
	$ pg_dump -t '"Test"' test
	--
	-- PostgreSQL database dump
	...

and vacuumdb certainly does not:

	vacuumdb --analyze --verbose --table 'foo(bar)' xyzzy

	$ vacuumdb --analyze --verbose --table 'Test (x)' test
	vacuumdb: vacuuming of table "Test (x)" in database "test" failed: ERROR:  relation "test" does not exist
	$ vacuumdb --analyze --verbose --table '"Test" (x)' test
	INFO:  vacuuming "public.Test"
	INFO:  "Test": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
	...

Who does?  reindexdb and clusterdb did before my patch, but that hardly
seems consistent.

-- 
  Bruce Momjian  <[email protected]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

view thread (18+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: createuser/dropuser username
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox