On 02/03/2013 08:20 PM, Robert Haas wrote:
On Fri, Feb 1, 2013 at 6:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Daniel Farina <dan...@heroku.com> writes:
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas <robertmh...@gmail.com> wrote:
I think it's smarter for us to ship functions, and let users wrap them
in operators if they so choose. It's not difficult for people who
The problem being: even though pg_operator resolves to functions in
pg_proc, they have distinct identities as far as the planner is
concerned w.r.t selectivity estimation and index selection.
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).
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
