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
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
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
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
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
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 ag
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 problem with compilation
Nobody had objections in discussion
There are enough regress tests and documentation
check
Training &
Services
This patch is based on transformation CYCLE and SEARCH clauses to
specific expressions - it is in agreement with ANSI SQL
There is not a problem with compilation
Nobody had objections in discussion
There are enough regress tests and documentation
check-world pas
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
moved the whole rewrite
>> support to a new file to not blow up rewriteHandler.c so much.
>>
>> --
>> Peter Eisentraut http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>
This patch i
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
eter 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 ++-
doc/src/sgml/ref/select.
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 =
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
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...@2
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
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
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
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
