David Johnston wrote
> The paragraph is unnecessary if the Synopsis section of the SELECT
> documentation is updated to correctly reflect all the valid clauses that
> can be attached to TABLE. The current reading implies that you cannot
> attach anything so when you said LIMIT worked I was surprised.
>
> Also, testing seems to confirm that the allowance of LIMIT implies that
> OFFSET is allowed as well.
>
> If TABLE is allowed as a top-level command why doesn't it get its own page
> in the SQL commands section? It really doesn't matter - and honestly
> while I've known about it I've never actually thought to use it in actual
> queries because as soon as you want to do something special you have to
> switch it out for SELECT * FROM anyway - but it does seem inconsistent.
I'd be in favour of the first. Since it's sort-of synonymous for SELECT *
FROM it would make sense to include it on the same page to avoid having to
explain the same clauses again. But then it should be listed earlier, before
the clauses which can be used with it.
Yes, all LIMIT, OFFSET, FETCH stuff works. Also very useful in a WITH:
WITH x AS ( TABLE foo ORDER BY colX DESC LIMIT 10
)
...;
Note that set operations work too, and that's how I most often use it for
testing rewritten queries:
create table x as <original_query>;
create table y as <rewritten_query>;
table x except table y;
table y except table x;
Cheers,
Colin
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/TABLE-not-synonymous-with-SELECT-FROM-tp5777695p5777883.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
