| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: allow psql to watch \dt |
| Date: | 2018-05-12 01:30:01 |
| Message-ID: | 22703.1526088601@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> I thought that would be desirable, although I don't see any better way of
> getting there than this.
Hm, but a lot of the \d commands involve more than one underlying query,
as well as a bunch of postprocessing. I doubt that the approach you seem
to be using here can handle such cases.
I think you have also stomped all over the semantics of
query-buffer-related commands that are executed in the vicinity of a \d.
Up to now, \d didn't change the query buffer. That has its uses, eg
select somecol
\dt some* -- how's that table spelled again?
from sometable;
We could maybe think about making it work by moving the \watch repetition
up a level, so that exec_command() as a whole would be repeated ... but
I wonder what people would think repetition of other commands such as \i,
\e, \r, \if, etc etc should mean.
On the whole I think this is not a can of worms I want to open. There's
a clear distinction right now between plain SQL and backslash commands,
and this is going to fuzz that in ways that are hard to predict the
consequences of.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-05-12 02:24:41 | Re: Compiler warnings with --enable-dtrace |
| Previous Message | Justin Pryzby | 2018-05-12 00:38:46 | allow psql to watch \dt |