> The last time this was discussed (
> https://www.postgresql.org/message-id/1037735.1610402426%40sss.pgh.pa.us)
> it was suggested to make the feature generalizable, beyond what the
> standard says it should be limited to.
I have read the mail. In my understanding nobody said that standard
On Sat, 6 May 2023, 04:57 Tatsuo Ishii, wrote:
> Attached is the patch to implement this (on top of your patch).
>
> test=# SELECT row_number() RESPECT NULLS OVER () FROM (SELECT 1) AS s;
> ERROR: window function row_number cannot have RESPECT NULLS or IGNORE
> NULLS
>
The last time this was
>> The attached test patch is mostly the same as in the previous patch
>> set, but it doesn't fail on row_number anymore as the main patch
>> only rejects aggregate functions. The test patch also adds a test for
>
>> +SELECT sum(orbit) RESPECT NULLS OVER () FROM planets; -- succeeds
>
> I think
> The attached test patch is mostly the same as in the previous patch
> set, but it doesn't fail on row_number anymore as the main patch
> only rejects aggregate functions. The test patch also adds a test for
> +SELECT sum(orbit) RESPECT NULLS OVER () FROM planets; -- succeeds
I think the
On Sun, Apr 23, 2023 at 4:29 AM Tatsuo Ishii wrote:
> > Vik Fearing writes:
> >
> >> For me, this is perfectly okay. Keep them at the lowest level of
> >> reservation as possible.
> >
> > Yeah, keep them unreserved if at all possible. Any higher reservation
> > level risks breaking existing
> Vik Fearing writes:
>> On 4/22/23 14:14, Tatsuo Ishii wrote:
>>> Note that RESPECT/IGNORE are not registered as reserved keywords in
>>> this patch (but registered as unreserved keywords). I am not sure if
>>> this is acceptable or not.
>
>> For me, this is perfectly okay. Keep them at the
> Excellent. I was thinking about picking my version of this patch up
> again, but I think this might be better than mine.
Thanks.
> I am curious why set_mark is false in the IGNORE version instead of
> also being const_offset. Surely the nth non-null in the frame will
> never go backwards.
Vik Fearing writes:
> On 4/22/23 14:14, Tatsuo Ishii wrote:
>> Note that RESPECT/IGNORE are not registered as reserved keywords in
>> this patch (but registered as unreserved keywords). I am not sure if
>> this is acceptable or not.
> For me, this is perfectly okay. Keep them at the lowest
On 4/22/23 14:14, Tatsuo Ishii wrote:
I revisited the thread:
https://www.postgresql.org/message-id/flat/CAGMVOdsbtRwE_4%2Bv8zjH1d9xfovDeQAGLkP_B6k69_VoFEgX-A%40mail.gmail.com
and came up with attached POC patch (I used some varibale names
appearing in the Krasiyan Andreev's patch). I really
On Sat, 22 Apr 2023, 13:14 Tatsuo Ishii, wrote:
> I revisited the thread:
>
> https://www.postgresql.org/message-id/flat/CAGMVOdsbtRwE_4%2Bv8zjH1d9xfovDeQAGLkP_B6k69_VoFEgX-A%40mail.gmail.com
>
> and came up with attached POC patch (I used some varibale names
> appearing in the Krasiyan
I revisited the thread:
https://www.postgresql.org/message-id/flat/CAGMVOdsbtRwE_4%2Bv8zjH1d9xfovDeQAGLkP_B6k69_VoFEgX-A%40mail.gmail.com
and came up with attached POC patch (I used some varibale names
appearing in the Krasiyan Andreev's patch). I really love to have
RESPECT/IGNORE NULLS because
Thank you very much for feedback and yes, that is very useful SQL syntax.
Maybe you miss my previous answer, but you are right, that patch is
currently dead,
because some important design questions must be discussed here, before
patch rewriting.
I have dropped support of from first/last for
Greetings,
This seems to have died out, and that's pretty unfortunate because this
is awfully useful SQL standard syntax that people look for and wish we
had.
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> So I've tried to rough out a decision tree for the various options on
> how this
> "Krasiyan" == Krasiyan Andreev writes:
Krasiyan> I am using last version from more than two months ago in
Krasiyan> production environment with real data and I didn't find any
Krasiyan> bugs, so I'm marking this patch as ready for committer in the
Krasiyan> commitfest app.
Oliver (or
> "Tom" == Tom Lane writes:
>> So I've tried to rough out a decision tree for the various options
>> on how this might be implemented (discarding the "use precedence
>> hacks" option). Opinions? Additions?
Tom> I think it'd be worth at least drafting an implementation for the
Tom>
Andrew Gierth writes:
> So I've tried to rough out a decision tree for the various options on
> how this might be implemented (discarding the "use precedence hacks"
> option). Opinions? Additions?
I think it'd be worth at least drafting an implementation for the
lexical-lookahead fix. I think
So I've tried to rough out a decision tree for the various options on
how this might be implemented (discarding the "use precedence hacks"
option). Opinions? Additions?
(formatted for emacs outline-mode)
* 1. use lexical lookahead
+: relatively straightforward parser changes
+: no new
> "Tom" == Tom Lane writes:
>> select nth_value(x) from first ignore;
Tom> No, because once IGNORE is a keyword, even unreserved, it's not
Tom> legal as an AS-less alias.
That rule only applies in the select-list, not in the FROM clause; table
aliases in FROM are just ColId, so they can
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> If you just think of recognizing FROM FIRST/LAST, you get nowhere
> Tom> because that's still legal in other contexts. But if you were to
> Tom> look for FROM followed by FIRST/LAST followed by
> Tom> IGNORE/RESPECT/OVER, I think that
> "Tom" == Tom Lane writes:
Tom> If you just think of recognizing FROM FIRST/LAST, you get nowhere
Tom> because that's still legal in other contexts. But if you were to
Tom> look for FROM followed by FIRST/LAST followed by
Tom> IGNORE/RESPECT/OVER, I think that could only validly happen
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The FROM FIRST/LAST bit seems particularly badly thought through,
> Tom> because AFAICS it is flat out ambiguous with a normal FROM clause
> Tom> immediately following the window function call. The only way to
> Tom> make it not so
> "Tom" == Tom Lane writes:
Tom> The FROM FIRST/LAST bit seems particularly badly thought through,
Tom> because AFAICS it is flat out ambiguous with a normal FROM clause
Tom> immediately following the window function call. The only way to
Tom> make it not so would be to make FIRST and
Andrew Gierth writes:
> Normally I'd push hard to try and get some solution that's sufficiently
> generic to allow user-defined functions to make use of the feature. But
> I think the SQL spec people have managed to make that literally
> impossible in this case, what with the FROM keyword
> "Krasiyan" == Krasiyan Andreev writes:
Krasiyan> Hi,
Krasiyan> Patch applies and compiles, all included tests and building
Krasiyan> of the docs pass. I am using last version from more than two
Krasiyan> months ago in production environment with real data and I
Krasiyan> didn't find
Hi,
Patch applies and compiles, all included tests and building of the docs
pass.
I am using last version from more than two months ago in production
environment with real data and I didn't find any bugs,
so I'm marking this patch as ready for committer in the commitfest app.
На сб, 28.07.2018 г.
On Fri, Jul 13, 2018 at 01:52:00PM +0100, Oliver Ford wrote:
> Adds the options RESPECT/IGNORE NULLS (null treatment clause) and FROM
> FIRST/LAST to the non-aggregate window functions.
Please find attached an updated version for OID drift.
Best,
David.
--
David Fetter http://fetter.org/
Adds the options RESPECT/IGNORE NULLS (null treatment clause) and FROM
FIRST/LAST to the non-aggregate window functions.
A previous patch
(https://www.postgresql.org/message-id/CA+=vxna5_n1q5q5okxc0aqnndbo2ru6gvw+86wk+onsunjd...@mail.gmail.com)
partially implemented this feature. However, that
27 matches
Mail list logo
