Re: proposal: type info support functions for functions that use "any" type

2021-03-03 Thread Pavel Stehule
st 3. 3. 2021 v 18:12 odesílatel David Steele napsal: > > pá 31. 7. 2020 v 2:32 odesílatel Tom Lane > > napsal: > > > > So my opinion is still what it was in January. > > Since there does not appear to be support for this patch and it has not > attracted any new

Re: proposal: type info support functions for functions that use "any" type

2021-03-03 Thread David Steele
pá 31. 7. 2020 v 2:32 odesílatel Tom Lane > napsal: So my opinion is still what it was in January. Since there does not appear to be support for this patch and it has not attracted any new review or comment in the last year I'm planning to close it on MAR 8

Re: proposal: type info support functions for functions that use "any" type

2020-07-31 Thread Pavel Stehule
pá 31. 7. 2020 v 2:32 odesílatel Tom Lane napsal: > Daniel Gustafsson writes: > > This patch has been bumped in CFs for the past year, with the thread > stalled > > and the last review comment being in support of rejection. Tom, do you > still > > feel it should be rejected in light of Pavel's

Re: proposal: type info support functions for functions that use "any" type

2020-07-30 Thread Tom Lane
Daniel Gustafsson writes: > This patch has been bumped in CFs for the past year, with the thread stalled > and the last review comment being in support of rejection. Tom, do you still > feel it should be rejected in light of Pavel's latest posts? I have seen no convincing response to the

Re: proposal: type info support functions for functions that use "any" type

2020-07-30 Thread Daniel Gustafsson
> On 26 Jan 2020, at 16:33, Pavel Stehule wrote: > I reread all related mails and I think so it should be safe - or there is > same risk like using any C extensions for functions or hooks. This patch has been bumped in CFs for the past year, with the thread stalled and the last review comment

Re: proposal: type info support functions for functions that use "any" type

2020-01-26 Thread Pavel Stehule
Hi út 14. 1. 2020 v 22:09 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > [ parser-support-function-with-demo-20191128.patch ] > > TBH, I'm still not convinced that this is a good idea. Restricting > the support function to only change the function's return type is > safer than the

Re: proposal: type info support functions for functions that use "any" type

2020-01-15 Thread Pavel Stehule
st 15. 1. 2020 v 11:04 odesílatel Pavel Stehule napsal: > > > út 14. 1. 2020 v 22:09 odesílatel Tom Lane napsal: > >> Pavel Stehule writes: >> > [ parser-support-function-with-demo-20191128.patch ] >> >> TBH, I'm still not convinced that this is a good idea. Restricting >> the support

Re: proposal: type info support functions for functions that use "any" type

2020-01-15 Thread Pavel Stehule
út 14. 1. 2020 v 22:09 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > [ parser-support-function-with-demo-20191128.patch ] > > TBH, I'm still not convinced that this is a good idea. Restricting > the support function to only change the function's return type is > safer than the

Re: proposal: type info support functions for functions that use "any" type

2020-01-14 Thread Tom Lane
Pavel Stehule writes: > [ parser-support-function-with-demo-20191128.patch ] TBH, I'm still not convinced that this is a good idea. Restricting the support function to only change the function's return type is safer than the original proposal, but it's still not terribly safe. If you change

Re: proposal: type info support functions for functions that use "any" type

2019-11-27 Thread Pavel Stehule
Hi pá 16. 8. 2019 v 8:41 odesílatel Pavel Stehule napsal: > Hi > > rebase > another rebase Regards Pavel > Pavel > diff --git a/contrib/Makefile b/contrib/Makefile index 92184ed487..dafa42844d 100644 --- a/contrib/Makefile +++ b/contrib/Makefile @@ -15,6 +15,7 @@ SUBDIRS = \ citext \

Re: proposal: type info support functions for functions that use "any" type

2019-08-16 Thread Pavel Stehule
Hi rebase Pavel diff --git a/contrib/decode/.gitignore b/contrib/decode/.gitignore new file mode 100644 index 00..5dcb3ff972 --- /dev/null +++ b/contrib/decode/.gitignore @@ -0,0 +1,4 @@ +# Generated subdirectories +/log/ +/results/ +/tmp_check/ diff --git a/contrib/decode/Makefile

Re: proposal: type info support functions for functions that use "any" type

2019-08-07 Thread Pavel Stehule
Hi pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal: > I wrote: > > TBH, I don't like this proposal one bit. As far as I can see, the idea > > is to let a function's support function redefine the function's declared > > argument and result types on-the-fly according to no predetermined rules,

Re: proposal: type info support functions for functions that use "any" type

2019-08-07 Thread Pavel Stehule
čt 1. 8. 2019 v 11:01 odesílatel Thomas Munro napsal: > On Sat, Jul 27, 2019 at 5:45 PM Pavel Stehule > wrote: > > pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal: > >> I wrote: > >> > TBH, I don't like this proposal one bit. As far as I can see, the > idea > >> > is to let a function's

Re: proposal: type info support functions for functions that use "any" type

2019-08-01 Thread Thomas Munro
On Sat, Jul 27, 2019 at 5:45 PM Pavel Stehule wrote: > pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal: >> I wrote: >> > TBH, I don't like this proposal one bit. As far as I can see, the idea >> > is to let a function's support function redefine the function's declared >> > argument and

Re: proposal: type info support functions for functions that use "any" type

2019-07-26 Thread Pavel Stehule
pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal: > I wrote: > > TBH, I don't like this proposal one bit. As far as I can see, the idea > > is to let a function's support function redefine the function's declared > > argument and result types on-the-fly according to no predetermined rules, > >

Re: proposal: type info support functions for functions that use "any" type

2019-07-26 Thread Pavel Stehule
pá 26. 7. 2019 v 22:03 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule > > napsal: > >> Tom introduced supported functions for calculation function's > selectivity. > >> Still I have similar idea to use supported function for calculation >

Re: proposal: type info support functions for functions that use "any" type

2019-07-26 Thread Tom Lane
I wrote: > TBH, I don't like this proposal one bit. As far as I can see, the idea > is to let a function's support function redefine the function's declared > argument and result types on-the-fly according to no predetermined rules, > and that seems to me like it's a recipe for disaster. How

Re: proposal: type info support functions for functions that use "any" type

2019-07-26 Thread Tom Lane
Pavel Stehule writes: > so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule > napsal: >> Tom introduced supported functions for calculation function's selectivity. >> Still I have similar idea to use supported function for calculation >> function's parameter's types and function return type. >>

Re: proposal: type info support functions for functions that use "any" type

2019-04-01 Thread Pavel Stehule
Hi so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule napsal: > Hi, > > Tom introduced supported functions for calculation function's selectivity. > Still I have similar idea to use supported function for calculation > function's parameter's types and function return type. > > Motivation: > > Reduce

proposal: type info support functions for functions that use "any" type

2019-03-08 Thread Pavel Stehule
Hi, Tom introduced supported functions for calculation function's selectivity. Still I have similar idea to use supported function for calculation function's parameter's types and function return type. Motivation: Reduce a necessity of overloading of functions. My motivation is related primary