On Tue, 2008-11-18 at 10:36 -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Tue, Nov 18, 2008 at 04:01:58PM +0200, Peter Eisentraut wrote:
> >> I was looking into that and I figured using the \G expression in
> >> Perl REs would be useful for this (to find multiple s).
> >
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Nov 18, 2008 at 04:01:58PM +0200, Peter Eisentraut wrote:
>> I was looking into that and I figured using the \G expression in
>> Perl REs would be useful for this (to find multiple s).
>> But this was introduced in Perl 5.000, and we claim to sup
On Tue, Nov 18, 2008 at 04:01:58PM +0200, Peter Eisentraut wrote:
> Tom Lane wrote:
>> 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
Tom Lane wrote:
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 VALUE
Tom Lane wrote:
"Robert Haas" <[EMAIL PROTECTED]> writes:
Incidentally, I noticed while looking at this that "\h with" also
fails, even though WITH can now be the first word of a valid SQL
statement. I think we ought to patch psql to return the same help for
WITH as it does for SELECT.
Hmm.
> 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
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Incidentally, I noticed while looking at this that "\h with" also
> fails, even though WITH can now be the first word of a valid SQL
> statement. I think we ought to patch psql to return the same help for
> WITH as it does for SELECT.
Hmm. Given the cu
Hi,
I was assigned to code-review this patch by pgsql-rrreviewers. I
don't have much to add to what's already been written, but here are my
thoughts.
1. I agree with Tom Lane's earlier comments that table_ref is not the
correct non-terminal. For example, this seems pretty strange:
rhaas=# table
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> + | TABLE table_ref
BTW, this seems to accept *way* more than is intended by the spec.
I think a closer approximation would be "TABLE relation_expr".
You could even make a case for "TABLE qualified_name", which is
what the letter o
Peter Eisentraut Wrote:
> If I read this right, SQL would allow writing
>
> TABLE foo;
Interesting; I managed to find it in the spec:
4) The
TABLE
is equivalent to the
( SELECT * FROM )
So going by that would the patch also have to support something like:
WITH a AS (SELECT * FROM b)
TABL
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If I read this right, SQL would allow writing
> TABLE foo;
> as a top-level command, equivalent to SELECT * FROM foo; (see production
> ). It can be used whereever a SELECT or VALUES can be used.
> This is probably about as useless as some of my ot
If I read this right, SQL would allow writing
TABLE foo;
as a top-level command, equivalent to SELECT * FROM foo; (see production
). It can be used whereever a SELECT or VALUES can be used.
This is probably about as useless as some of my other recent patches,
but the implementation is simpl
12 matches
Mail list logo
