Re: [HACKERS] So do we really *need* those substring() ops in tab-completion queries?

2010-01-03 Thread Martijn van Oosterhout
On Sat, Jan 02, 2010 at 08:21:35PM -0500, Tom Lane wrote: > 3. Inefficient. It seems likely to me that filtering on the prefix on > the backend side isn't going to be more efficient than doing it on the > client side, except maybe in the schema-name cases. If the conditions > were phrased in a wa

Re: [HACKERS] So do we really *need* those substring() ops in tab-completion queries?

2010-01-02 Thread Tom Lane
Greg Stark writes: > On Sun, Jan 3, 2010 at 1:21 AM, Tom Lane wrote: >>  If the conditions >> were phrased in a way that made them indexable, they might be worth the >> trouble --- but they aren't. > Wow, that is weird, especially since it's *easier* to write them > properly using LIKE anyways.

[HACKERS] So do we really *need* those substring() ops in tab-completion queries?

2010-01-02 Thread Tom Lane
This evening's argument about DO completion caused me to look a bit closer at tab-complete.c than I ever had before. I am now wondering exactly why we bother with all the logic like " WHERE substring(pg_catalog.quote_ident(rolname),1,%d)='%s'" in the SQL queries that it issues. It appears to m