From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Slow tab completion w/ lots of tables |
Date: | 2012-08-21 18:03:42 |
Message-ID: | 5302.1345572222@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> That's the kind of concern that I was expecting, to be honest. :) As
> Kevin's pointed out, it's not likely to be needed anyway.. There's a
> bit of an open question still regarding case-insensitive searching, but
> perhaps we let that be slow and only done if we don't get any answers
> back from a case-sensetive search?
Um, I don't believe we do any case-insensitive search now, do we?
> We'd essentially do: LIKE 'xx%', and then run quote_ident() on the
> result (I assume we can replace the whole word, right?). I'd also
> strip off any ", for the purposes of searching with tab-completion.
I think you might be saying the same thing I said in my prior message,
but not quite sure.
> I'm
> not sure how easy it'd be to have a fall-back setup. I do wonder if we
> should do what I often recommend my dev do though, which is to have a
> SQL or pl/pgsql function defined on the database-side, rather than
> sending large/complex queries to the database from the application..
The nice thing about keeping this knowledge on the psql side is it would
still work with older servers.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-08-21 18:04:53 | Re: Slow tab completion w/ lots of tables |
Previous Message | Tom Lane | 2012-08-21 17:52:06 | Re: Slow tab completion w/ lots of tables |