From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Tab completion of SET TRANSACTION ISOLATION |
Date: | 2006-01-31 14:29:30 |
Message-ID: | 3467.1138717770@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Some time ago, the tab completion code for the SET command was changed
> to read the list of available settings from the pg_settings table.
> This means that by the time you're done completing SET TRANSACTION
> ISOLATION, you've already sent a query and the command will be
> disallowed. It's not a major issue, but I figured I'd mention it
> since it confused me a while ago. If someone has an ingenious plan
> for working around this, let me know.
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 :-(
We also have the ability to check the current in-transaction status,
so one possibility is to read the variable list only if not within
a transaction (and we didn't do it already in the current session).
Making the behavior of tab completion be state-dependent may seem
like a non-starter, but really it is anyway --- anything involving
a query will stop working in a failed transaction.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2006-01-31 14:32:47 | Re: New project launched : PostgreSQL GUI Installer for |
Previous Message | Christopher Browne | 2006-01-31 14:14:35 | Re: New project launched : PostgreSQL GUI |