On 22.02.21 14:45, Vik Fearing wrote:
On 2/22/21 1:28 PM, Peter Eisentraut wrote:
On 22.02.21 11:05, Vik Fearing wrote:
This looks good to me, except that you forgot to add the feature stamp.
Attached is a small diff to apply on top of your patch to fix that.
The feature code is from SQL:2
On 2/22/21 1:28 PM, Peter Eisentraut wrote:
> On 22.02.21 11:05, Vik Fearing wrote:
>> This looks good to me, except that you forgot to add the feature stamp.
>> Attached is a small diff to apply on top of your patch to fix that.
>
> The feature code is from SQL:202x, whereas the table is relati
On 22.02.21 11:05, Vik Fearing wrote:
This looks good to me, except that you forgot to add the feature stamp.
Attached is a small diff to apply on top of your patch to fix that.
The feature code is from SQL:202x, whereas the table is relative to
SQL:2016. We could add it, but probably with
On 2/22/21 9:44 AM, Peter Eisentraut wrote:
> On 22.05.20 14:32, Peter Eisentraut wrote:
>>> As an improvement over the spec, I think the vast majority of people
>>> will be using simple true/false values. Can we make that optional?
>>>
>>> CYCLE f, t SET is_cycle USING path
>>>
>>> would be
On 22.05.20 14:32, Peter Eisentraut wrote:
As an improvement over the spec, I think the vast majority of people
will be using simple true/false values. Can we make that optional?
CYCLE f, t SET is_cycle USING path
would be the same as
CYCLE f, t SET is_cycle TO true DEFAULT false US
po 1. 2. 2021 v 19:02 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2020-11-25 20:35, Pavel Stehule wrote:
> > I checked this patch, and I didn't find any issue.
> >
> > make check-world passed
> > make doc passed
> >
> > I'll mark it as ready for committer
>
> This
On 2020-11-25 20:35, Pavel Stehule wrote:
I checked this patch, and I didn't find any issue.
make check-world passed
make doc passed
I'll mark it as ready for committer
This has been committed. Thanks.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
On 6/15/20 11:49 AM, Peter Eisentraut wrote:
> To fix the star expansion I had to add a little bit of infrastructure
> that could also be used as a more general facility "don't include this
> column in star expansion", so this could perhaps use some consideration
> from a more general angle as well
On 5/22/20 12:40 PM, Vik Fearing wrote:
>>> 2)
>>> This query is an infinite loop, as expected:
>>>
>>> with recursive a as (select 1 as b union all select b from a)
>>> table a;
>>>
>>> But it becomes an error when you add a cycle clause to it:
>>>
>>> with recursive a as (select 1 as b u
st 25. 11. 2020 v 14:06 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2020-10-10 07:25, Pavel Stehule wrote:
> > This patch is based on transformation CYCLE and SEARCH clauses to
> > specific expressions - it is in agreement with ANSI SQL
> >
> > There is not a probl
3:45 +0100
Subject: [PATCH v4] SEARCH and CYCLE clauses
Discussion:
https://www.postgresql.org/message-id/flat/db80ceee-6f97-9b4a-8ee8-3ba0c58e5...@2ndquadrant.com
---
doc/src/sgml/queries.sgml| 64 ++-
doc/src/sgml/ref/select.sgml | 44 ++
src/backend/catalog/de
On 10.10.2020 08:25, Pavel Stehule wrote:
Hi
pá 9. 10. 2020 v 12:17 odesílatel Pavel Stehule
mailto:pavel.steh...@gmail.com>> napsal:
pá 9. 10. 2020 v 11:40 odesílatel Peter Eisentraut
mailto:peter.eisentr...@2ndquadrant.com>> napsal:
On 2020-09-22 20:29, Pavel Stehule wrot
On Fri, May 22, 2020 at 5:25 AM Peter Eisentraut
wrote:
> This is something we need to think about. If we want to check at parse
> time whether the two values are not the same (and perhaps not null),
> then we either need to restrict the generality of what we can specify,
> or we need to be prepa
Hi
pá 9. 10. 2020 v 12:17 odesílatel Pavel Stehule
napsal:
>
>
> pá 9. 10. 2020 v 11:40 odesílatel Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> napsal:
>
>> On 2020-09-22 20:29, Pavel Stehule wrote:
>> > The result is correct. When I tried to use UNION instead UNION ALL, the
>> > pg cr
pá 9. 10. 2020 v 11:40 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2020-09-22 20:29, Pavel Stehule wrote:
> > The result is correct. When I tried to use UNION instead UNION ALL, the
> > pg crash
>
> I fixed the crash, but UNION [DISTINCT] won't actually work here b
n Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 9 Oct 2020 11:32:10 +0200
Subject: [PATCH v3] SEARCH and CYCLE clauses
Discussion:
https://www.postgresql.org/message-id/flat/db80ceee-6f97-9b4a-8ee8-3ba0c58e5...@2ndquadrant.com
---
doc/src/sgml/queries.sgml| 213 +++
Hi
I found another bug
create view xx as WITH recursive destinations (departure, arrival,
connections, cost, itinerary) AS
(SELECT f.departure, f.arrival, 1, price,
CAST(f.departure || f.arrival AS VARCHAR(2000))
FROM flights f
WHERE f.departure = 'New
Hi
út 22. 9. 2020 v 20:01 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> I have implemented the SEARCH and CYCLE clauses.
>
> This is standard SQL syntax attached to a recursive CTE to compute a
> depth- or breadth-first ordering and cycle detec
While the larger patch is being considered, I think some simpler and
separable pieces could be addressed.
Here is a patch that adjusts the existing cycle detection example and
test queries to put the cycle column before the path column. The CYCLE
clause puts them in that order, and so if we a
ort, Remote DBA, Training & Services
From f4fc5f63c53ba954066d38f968f54fb8fbf76c59 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 15 Jun 2020 11:43:52 +0200
Subject: [PATCH v2] SEARCH and CYCLE clauses
Discussion:
https://www.postgresql.org/message-id/flat/db80ceee-6f97-9b4a-8ee8-3ba0c58e5
On 2020-05-22 12:40, Vik Fearing wrote:
If you specify null, then the cycle check expression will always fail,
so it will abort after the first row. (We should perhaps prohibit
specifying null, but see below.)
I would rather make the cycle check expression work with null.
It works correctly
On 5/22/20 11:24 AM, Peter Eisentraut wrote:
> On 2020-05-20 21:28, Vik Fearing wrote:
>> 1)
>> There are some smart quotes in the comments that should be converted to
>> single quotes.
>
> ok, fixing that
>
>> 2)
>> This query is an infinite loop, as expected:
>>
>> with recursive a as (selec
pá 22. 5. 2020 v 11:25 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2020-05-20 21:28, Vik Fearing wrote:
> > 1)
> > There are some smart quotes in the comments that should be converted to
> > single quotes.
>
> ok, fixing that
>
> > 2)
> > This query is an infinite
On 2020-05-20 21:28, Vik Fearing wrote:
1)
There are some smart quotes in the comments that should be converted to
single quotes.
ok, fixing that
2)
This query is an infinite loop, as expected:
with recursive a as (select 1 as b union all select b from a)
table a;
But it becomes an er
On 5/20/20 3:04 PM, Vik Fearing wrote:
> I'm looking forward to reviewing this.
A few quick things I've noticed so far:
1)
There are some smart quotes in the comments that should be converted to
single quotes.
2)
This query is an infinite loop, as expected:
with recursive a as (select 1 as b
On 5/20/20 1:46 PM, Peter Eisentraut wrote:
> I have implemented the SEARCH and CYCLE clauses.
YES!
> This is standard SQL syntax attached to a recursive CTE to compute a
> depth- or breadth-first ordering and cycle detection, respectively. This
> is just convenience syntax for
I have implemented the SEARCH and CYCLE clauses.
This is standard SQL syntax attached to a recursive CTE to compute a
depth- or breadth-first ordering and cycle detection, respectively.
This is just convenience syntax for what you can already do manually.
The original discussion about
27 matches
Mail list logo
