On 23.03.21 00:18, Tom Lane wrote:
However, ParseNamespaceItem as it stands needs some help for this.
It has a wired-in assumption that p_rte->eref describes the table
and column aliases exposed by the nsitem. 0001 below fixes this by
creating a separate p_names field in an nsitem. (There are
Peter Eisentraut writes:
> I think Tom's input on the guts of this patch would be most valuable,
> since it intersects a lot with the parse namespace refactoring he did.
I really didn't like the way you'd done that :-(. My primary complaint
is that any one ParseNamespaceItem can describe only o
Peter Eisentraut writes:
> I think Tom's input on the guts of this patch would be most valuable,
> since it intersects a lot with the parse namespace refactoring he did.
Yeah, I've been meaning to take a look. I'll try to get it done in
the next couple of days.
regards,
On 05.03.21 18:00, David Steele wrote:
On 11/14/20 3:49 AM, Peter Eisentraut wrote:
On 2020-11-10 16:15, Georgios Kokolatos wrote:
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waitin
On 11/14/20 3:49 AM, Peter Eisentraut wrote:
On 2020-11-10 16:15, Georgios Kokolatos wrote:
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is a rebased and lightl
On 2020-08-03 19:44, Wolfgang Walther wrote:
So given this:
SELECT x.id FROM a LEFT JOIN b USING (id) AS x
will this return NULL or a.id for rows that don't match in b? This
should definitely be mentioned in the docs and I guess a test wouldn't
be too bad as well?
This issue is independent of
On 2020-11-10 16:15, Georgios Kokolatos wrote:
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is a rebased and lightly retouched patch.
--
Peter Eisentraut
2ndQua
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Peter Eisentraut:
On 2019-12-31 00:07, Vik Fearing wrote:
One thing I notice is that the joined columns are still accessible from
their respective table names when they should not be per spec. That
might be one of those "silly restrictions" that we choose to ignore, but
it should probably be no
> On 27 Jan 2020, at 10:19, Peter Eisentraut
> wrote:
>
> On 2019-12-31 00:07, Vik Fearing wrote:
>> One thing I notice is that the joined columns are still accessible from
>> their respective table names when they should not be per spec. That
>> might be one of those "silly restrictions" that
On 2019-12-31 00:07, Vik Fearing wrote:
One thing I notice is that the joined columns are still accessible from
their respective table names when they should not be per spec. That
might be one of those "silly restrictions" that we choose to ignore, but
it should probably be noted somewhere, at t
Hello Peter,
I took another crack at this. Attached is a new patch that addresses
the semantic comments from this and the other thread. It's all a bit
tricky, comments welcome.
It seems that this patch does not apply anymore after Tom's 5815696.
--
Fabien.
On 30/12/2019 22:25, Peter Eisentraut wrote:
> On 2019-12-24 19:13, Fabien COELHO wrote:
Indeed, that seems like a problem, and it's a good question. You can
see this on unpatched master with SELECT x.filler FROM
(pgbench_tellers AS t JOIN b USING (bid)) AS x.
>>>
>>> I'm not sure I
On 2019-12-24 19:13, Fabien COELHO wrote:
Indeed, that seems like a problem, and it's a good question. You can
see this on unpatched master with SELECT x.filler FROM
(pgbench_tellers AS t JOIN b USING (bid)) AS x.
I'm not sure I understand why that problem is a blocker for this patch.
As dis
On Tue, 17 Sep 2019, Alvaro Herrera wrote:
Indeed, that seems like a problem, and it's a good question. You can
see this on unpatched master with SELECT x.filler FROM
(pgbench_tellers AS t JOIN b USING (bid)) AS x.
I'm not sure I understand why that problem is a blocker for this patch.
As
On 2019-09-17 19:37, Alvaro Herrera wrote:
> On 2019-Aug-01, Thomas Munro wrote:
>
>> Indeed, that seems like a problem, and it's a good question. You can
>> see this on unpatched master with SELECT x.filler FROM
>> (pgbench_tellers AS t JOIN b USING (bid)) AS x.
>
> I'm not sure I understand wh
On 2019-Aug-01, Thomas Munro wrote:
> Indeed, that seems like a problem, and it's a good question. You can
> see this on unpatched master with SELECT x.filler FROM
> (pgbench_tellers AS t JOIN b USING (bid)) AS x.
I'm not sure I understand why that problem is a blocker for this patch.
--
Álvar
On Tue, Jul 16, 2019 at 8:58 AM Fabien COELHO wrote:
> About the feature:
>
> When using aliases both on tables and on the unifying using clause, the former
> are hidden from view. I cannot say that I understand why, and this makes it
> impossible to access some columns in some cases if there is a
Hello Peter,
A small new feature in SQL:2016 allows attaching a table alias to a
JOIN/USING construct:
::=
USING
[ AS ]
(The part in brackets is new.)
This seems quite useful, and it seems the code would already support
this if we allow the grammar to accept this syntax.
On Tue, Jun 18, 2019 at 2:41 AM Peter Eisentraut
wrote:
> A small new feature in SQL:2016 allows attaching a table alias to a
> JOIN/USING construct:
>
> ::=
> USING
> [ AS ]
>
> (The part in brackets is new.)
>
> This seems quite useful, and it seems the code would already su
lias to be attached directly to a JOIN ... USING
This allows something like
SELECT ... FROM t1 JOIN t2 USING (a, b, c) AS x
instead of requiring parentheses for the alias like
SELECT ... FROM (t1 JOIN t2 USING (a, b, c)) AS x
per SQL:2016 feature F404 "Range variable for common col
21 matches
Mail list logo
