On 1/2/17 12:25 PM, Robert Haas wrote:
But, I can easily imagine a good number of people deciding they want
mixed case on the server, and so quoting their identifiers. And, then
deciding PostgreSQL is defective, rather than deciding their favorite
administration or query tool is defective. Almost all of the tools I
tried worked fine when I had all lower case symbols on the server. Based
on observing the generated SQL, most of the tools that failed for me
when I had mixed case symbols on the server would work against a case
preserving mode in PostgreSQL. The tools generally pass through the
catalog reported symbols without manipulation.
Right.  Tom's argument makes a lot of sense when you think about this
from the point of view of someone writing extensions or tools that are
designed to work with anybody's PostgreSQL instance.  When you think
about it from the point of view of a user wanting to write an
application that can work with any of a number of databases, then your
argument has a lot of merit to it.  I'm not sure there's any way to
split the baby here: tool authors will obviously prefer that
PostgreSQL's behavior in this area be invariable, while people trying
to develop portable database applications will prefer configurability.
As far as I can see, this is a zero sum game that is bound to have one
winner and one loser.

I do wonder what the authors of those tools are using to test them. My guess is they're just hitting the default postgres database, which has no quotable identifiers.

I'd find it useful to have a contrib module/tool that would create a full-blown test database that contains objects of every possible type, including using identifiers that need quotes. It'd also be useful to test leading and trailing whitespace.

Having this would be useful for seeing what some of the more unusual objects look like in the catalog, and would simplify tests that I create for my extensions somewhat. If tool authors knew it existed they could use it for testing. It'd certainly be useful for testing things like pg_dump and event triggers.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to