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.
Right. > 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: http://www.postgresql.org/mailpref/pgsql-hackers
