Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Tab completion of SET TRANSACTION ISOLATION


  • From: Greg Stark <gsstark(at)mit(dot)edu>
  • To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: Tab completion of SET TRANSACTION ISOLATION
  • Date: 31 Jan 2006 16:19:18 -0500
  • Message-id: <87vew0p02x(dot)fsf(at)stark(dot)xeocode(dot)com>

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Hm, that's a bit nasty.
> 
> The only plan I can think of involves reading the list of available
> variable names in advance and keeping it around.  However, I'm not
> sure I want psql issuing such a query at connection startup whether
> or not the info will ever be used :-(

Well, it could just lazily cache the data if it's ever fetched. That would at
least limit the occurrence of this problem to only happening once per
connection.

psql could also hard code "SET TRANSACTION ISOLATION" specifically. If psql
knew that "SET TRANS" completes to SET TRANSACTION and "SET TRANSACTION I"
completes to "SET TRANSACTION ISOLATION" it could avoid doing the query at
all. 

That would only fail if someone uses TAB to view the available completions for
"SET" or any shorter string. And since transaction isolation is strangely
absent from the list of completions that seems like not such a big concern. If
he's doing that he's not going to find it anyways.

-- 
greg




Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group