From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TABLE command |
Date: | 2008-11-08 20:17:34 |
Message-ID: | 603c8f070811081217p17dd578foaf4526d8ec2d8eff@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Hmm. Given the current infrastructure for \h, the only way to do that
> would be to make a separate ref page for WITH, which feels like the
> wrong thing. And the objection I have to TABLE is not the code but the
> apparent need to give it its own ref page (as we already did for VALUES,
> and I found that pretty ugly too).
Suck it up. :-) Presumably there could be more things in this
category in the future, so we'd better figure out how to handle it.
I just noticed that, at present, "\h WI" tab-completes to "\h WITH"
and then to "\h WITH RECURSIVE", but hitting return then tells you
that no help is actually available, which is pretty horrible.
> Is there a way to make all of these point at the SELECT ref page?
I think we could probably modify helpSQL() to support a list of
aliases. I'm not sure how tricky that would be - the existing logic
appears slightly byzantine. I'll take a crack at it if you would
like.
> Something cleaner than a special hack in psql would be nice, but
> I guess I'd settle for that as still an improvement over considering
> that TABLE is a command. The problem with documenting VALUES and
> TABLE as commands is that this doesn't reflect their principal use
> as elements of a SELECT; and it also becomes quite unclear why you can't
> use, say, EXPLAIN or SHOW as elements of a SELECT.
Well, I suppose we could make it so that they can be. *ducks*
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2008-11-08 20:25:14 | [PATCH] Recreate Missing WAL Directories (from TODO) |
Previous Message | Tom Lane | 2008-11-08 20:07:30 | Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle |