Re: Compatible defaults for LEAD/LAG

st 4. 11. 2020 v 22:12 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > út 22. 9. 2020 v 2:33 odesílatel Tom Lane napsal: > >> Anyway, attached find > >> 0001 - updates Vik's original patch to HEAD and tweaks the > >> grammar in the docs a bit. > >> 0002 - add-on patch to convert array_a

Re: Compatible defaults for LEAD/LAG

Pavel Stehule writes: > út 22. 9. 2020 v 2:33 odesílatel Tom Lane napsal: >> Anyway, attached find >> 0001 - updates Vik's original patch to HEAD and tweaks the >> grammar in the docs a bit. >> 0002 - add-on patch to convert array_append, array_prepend, >> array_cat, array_position, array_positio

Re: Compatible defaults for LEAD/LAG

út 22. 9. 2020 v 2:33 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I see few possibilities how to finish and close this issue: > > 1. use anycompatible type and add note to documentation so expression of > > optional argument can change a result type, and so this is Postgres > > speci

Re: Compatible defaults for LEAD/LAG

Pavel Stehule writes: > I see few possibilities how to finish and close this issue: > 1. use anycompatible type and add note to documentation so expression of > optional argument can change a result type, and so this is Postgres > specific - other databases and ANSI SQL disallow this. > It is the

Re: Compatible defaults for LEAD/LAG

po 31. 8. 2020 v 7:05 odesílatel Pavel Stehule napsal: > > > ne 30. 8. 2020 v 23:59 odesílatel Tom Lane napsal: > >> Pavel Stehule writes: >> > This is nice example of usage of anycompatible type (that is consistent >> > with other things in Postgres), but standard says something else. >> > It

Re: Compatible defaults for LEAD/LAG

ne 30. 8. 2020 v 23:59 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > This is nice example of usage of anycompatible type (that is consistent > > with other things in Postgres), but standard says something else. > > It can be easily solved with https://commitfest.postgresql.org/28/2081/

Re: Compatible defaults for LEAD/LAG

Pavel Stehule writes: > This is nice example of usage of anycompatible type (that is consistent > with other things in Postgres), but standard says something else. > It can be easily solved with https://commitfest.postgresql.org/28/2081/ - > but Tom doesn't like this patch. > I am more inclined to

Re: Compatible defaults for LEAD/LAG

čt 23. 7. 2020 v 13:29 odesílatel Daniel Gustafsson napsal: > > On 13 Jul 2020, at 19:23, Pavel Stehule wrote: > > > ne 31. 5. 2020 v 22:02 odesílatel Vik Fearing > napsal: > > On 5/31/20 9:53 PM, Tom Lane wrote: > > > Vik Fearing mailto:v...@postgresfriends.org

Re: Compatible defaults for LEAD/LAG

> On 13 Jul 2020, at 19:23, Pavel Stehule wrote: > ne 31. 5. 2020 v 22:02 odesílatel Vik Fearing > napsal: > On 5/31/20 9:53 PM, Tom Lane wrote: > > Vik Fearing mailto:v...@postgresfriends.org>> > > writes: > >> postgres=# SELECT LAG(n, 1, -99) OVER (ORDER BY

Re: Compatible defaults for LEAD/LAG

Hi ne 31. 5. 2020 v 22:02 odesílatel Vik Fearing napsal: > On 5/31/20 9:53 PM, Tom Lane wrote: > > Vik Fearing writes: > >> postgres=# SELECT LAG(n, 1, -99) OVER (ORDER BY n) > >> postgres-# FROM (VALUES (1.1), (2.2), (3.3)) AS v (n) > >> postgres-# ORDER BY n; > >> ERROR: function lag

Re: Compatible defaults for LEAD/LAG

po 1. 6. 2020 v 17:36 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > po 1. 6. 2020 v 4:07 odesílatel Tom Lane napsal: > >> That's just the tip of the iceberg, though. If you consider all the > >> old-style polymorphic types, we have [for example] > >> array_append(anyarray,anyelement)

Re: Compatible defaults for LEAD/LAG

Pavel Stehule writes: > po 1. 6. 2020 v 4:07 odesílatel Tom Lane napsal: >> That's just the tip of the iceberg, though. If you consider all the >> old-style polymorphic types, we have [for example] >> array_append(anyarray,anyelement) > I am not sure, if using anycompatible for buildin's array

Re: Compatible defaults for LEAD/LAG

po 1. 6. 2020 v 4:07 odesílatel Tom Lane napsal: > Vik Fearing writes: > > On 5/31/20 9:53 PM, Tom Lane wrote: > >> When the anycompatible patch went in, I thought for a little bit about > >> trying to use it with existing built-in functions, but didn't have the > >> time to investigate the issu

Re: Compatible defaults for LEAD/LAG

Vik Fearing writes: > On 5/31/20 9:53 PM, Tom Lane wrote: >> When the anycompatible patch went in, I thought for a little bit about >> trying to use it with existing built-in functions, but didn't have the >> time to investigate the issue in detail. I'm not in favor of hacking >> things one-funct

Re: Compatible defaults for LEAD/LAG

On 5/31/20 9:53 PM, Tom Lane wrote: > When the anycompatible patch went in, I thought for a little bit about > trying to use it with existing built-in functions, but didn't have the > time to investigate the issue in detail. I'm not in favor of hacking > things one-function-at-a-time here; we shou

Re: Compatible defaults for LEAD/LAG

On 5/31/20 9:53 PM, Tom Lane wrote: > Vik Fearing writes: >> postgres=# SELECT LAG(n, 1, -99) OVER (ORDER BY n) >> postgres-# FROM (VALUES (1.1), (2.2), (3.3)) AS v (n) >> postgres-# ORDER BY n; >> ERROR: function lag(numeric, integer, integer) does not exist >> LINE 1: SELECT LAG(n, 1,

Re: Compatible defaults for LEAD/LAG

Vik Fearing writes: > postgres=# SELECT LAG(n, 1, -99) OVER (ORDER BY n) > postgres-# FROM (VALUES (1.1), (2.2), (3.3)) AS v (n) > postgres-# ORDER BY n; > ERROR: function lag(numeric, integer, integer) does not exist > LINE 1: SELECT LAG(n, 1, -99) OVER (ORDER BY n) >^

Compatible defaults for LEAD/LAG

I noticed that the PostgreSQL entry in a pan-database feature matrix by Modern SQL was not reflecting the reality of our features.[1] It turns out that test case used by the author produced an error which the tool took to mean the feature was not implemented. I don't have the actual test, but her