| 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: | Whole Thread | Raw Message | 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 |