On Sun, Feb 3, 2013 at 9:05 PM, Andrew Dunstan <and...@dunslane.net> wrote: >>> Yeah, this is surely not a workable policy unless we first move all >>> those planner smarts to apply to functions not operators. And rewrite >>> all the index AM APIs to use functions not operators, too. Now this is >>> something that's been a wish-list item right along, but actually doing >>> it has always looked like a great deal of work for rather small reward. >> >> Hmm. Well, if the operators are going to be indexable, then I agree >> that's an issue, but isn't -> just a key-extraction operator? That >> wouldn't be something you could index anyway. > > Er, what? It gives you the value corresponding to a key (or the numbered > array element).
That's what I figured. > With the Json operators I provided you're more likely to use ->> in an > index, because it returns de-escaped text rather than json, but I don't see > any reason in principle why -> couldn't be used. The point is that if you're talking about indexing something like myeav->'andrew' you could equally well index json_get(myeav, 'andrew'). So there's no real need for it to be an operator rather than a function. The case in which it would matter is if it were something that could be used as an index predicate, like: Index Scan -> Index Cond: myeav->'andrew' As of now, the query planner won't consider such a plan if it's only a function and not an operator. So if we had a case like that, the use of operator notation could be justified on performance grounds. If we don't, I argue that it's better to stick with functional notation, because the number of sensible function names is much larger than the number of sensible operator names, and if we start using operator notation every time someone thinks it will look nicer that way, we will very quickly either run out of nice-looking operator names or start overloading them heavily. 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. -- 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
