On Thu, Feb 23, 2017 at 6:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I think these are straw-man arguments, really. Consider the actual use > case for such a feature: it's for porting some application that was not > written against Postgres to begin with.
I'm not sure that's totally true. I think at least some requests for this feature are intended at satisfying somebody's sense of aesthetics. But I'll agree that the biggest use case is probably porting applications from other systems. Even then, though, people end up using PG-specific features as a way of working around stuff that other systems support using different syntax - e.g. T-SQL that works on SQL server might get turned into a DO block for PostgreSQL, and it's surprising if that causes you to suddenly get different case-folding rules. Also, people sometimes start by doing a port, and then later start using PG-specific features, which introduces the same kinds of problems. > The odds that such an app uses DO > blocks are exactly zero. It may well make use of server-side functions, > but those are going to require significant porting effort in any case. > So I think a case-folding function that could be interposed in front of > libpq or JDBC or $favorite_driver could well go a long way towards solving > that sort of problem. It wouldn't be 100%, sure, but if you hold your > breath and wait for a 100% solution to appear on the server side, you're > going to be quite blue. True, but that doesn't make a leaky abstraction not a hack. It just makes having a hack a practical improvement over not having one -- and I'm perfectly happy to concede that hacks are sometimes useful. -- 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
