On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas <robertmh...@gmail.com> wrote: > > 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. >
For what my opinion is worth I absolute agree with just having function names. The -> in hstore is kind of nice, but it lead me to a whole lot of greif when I couldn't figure out how to create an index using it (turns out you have to use _double_ parens, who knew?), but could create an index on fetchval and assumed that postgres would figure it out. Also a for quite a while it felt just like incantation of when I'd need parens around those operatiors or not. Now that I sorta-kinda-not-really understand the operation precedence rules in postgres/sql standard, I've mostly given up on using cute operators because their much more of a pain on a day-to-day basis.
