On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan <and...@dunslane.net> wrote: > On 02/04/2013 10:47 AM, Robert Haas wrote: >> >> >> The SQL standards considerations seem worth thinking about, too. >> We've certainly gone through a lot of pain working toward eliminating >> => as an operator name, and if the SQL standard has commandeered -> >> for some purpose or other, I'd really rather not add to the headaches >> involved should we ever decide to reclaim it. > > OK, but I'd like to know what is going to be safe. There's no way to > future-proof the language. I'm quite prepared to replace -> with something > else, and if I do then ->> will need to be adjusted accordingly, I think. > > My suggestion would be ~> and ~>>. I know David Wheeler didn't like that on > the ground that some fonts elevate ~ rather than aligning it in the middle > as most monospaced fonts do, but I'm tempted just to say "then use a > different font." Other possibilities that come to mind are +> and +>>, > although I think they're less attractive. But I'll be guided by the > consensus, assuming there is one ;-)
I suspect both of those are pretty safe from an SQL standards point of view. Of course, as Tom is often wont to point out, the SQL standards committee sometimes does bizarre things, so nothing's perfect, but I'd be rather shocked if any of those got tapped to mean something else. That having been said, I still don't see value in adding operators at all. Good old function call notation seems perfectly adequate from where I sit. Sure, it's a little more verbose, but when you try to too hard make things concise then you end up having to explain to your users why \ditS is a sensible thing for them to type into psql, or why s@\W@sprintf"%%%02x",ord($&)@e in Perl. I recognize that I may lose this argument, but I've worked with a couple of languages where operators can be overloaded (C++) or defined (ML) and it's just never seemed to work out very well. YMMV, of course. -- 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
