On Sun, Dec 25, 2016 at 4:40 AM, Lewis, Ian (Microstar Laboratories)
<ile...@mstarlabs.com> wrote:
> I assume you are talking about general purpose tools that attempt to
> interact with any database in any configuration. Obviously, a purpose
> built tool, such as our own internal database applications, would be
> designed only for the behavior of the databases it is intended to work
> against.


> So, the current behavior already breaks many tools unless one accepts
> that all symbols on the server are lower case. At root, based on reading
> the threads you provided, this probably indicates defects in the tools,
> rather than a problem with PostgreSQL. My reading of the standard text
> quoted in various places is that any mixed case identifier returned from
> the catalog has to be quoted to match in a query (whether you fold to
> lower or upper case).
> 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.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Reply via email to