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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: type info support functions for functions that use "any" type
Date: 2019-08-07 06:01:58
Message-ID: CAFj8pRD9hPaSzejXbeyA_MWHykpzHOGx8eAiH1ZM95k4TauYDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 1. 8. 2019 v 11:01 odesílatel Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
napsal:

> On Sat, Jul 27, 2019 at 5:45 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > pá 26. 7. 2019 v 22:53 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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,
> >> > and that seems to me like it's a recipe for disaster. How will anyone
> >> > understand which function(s) are candidates to match a query, or why
> one
> >> > particular candidate got selected over others? It's already hard
> enough
> >> > to understand the behavior of polymorphic functions in complex cases,
> >> > and those are much more constrained than this would be.
> >>
> >> After thinking about this a bit more, it seems like you could avoid
> >> a lot of problems if you restricted what the support function call
> >> does to be potentially replacing the result type of a function
> >> declared to return ANY with some more-specific type (computed from
> >> examination of the actual arguments). That would make it act much
> >> more like a traditional polymorphic function. It'd remove the issues
> >> about interactions among multiple potentially-matching functions,
> >> since we'd only call a single support function for an already-identified
> >> target function.
> >
> >
> > I am not sure if I understand well - so I repeat it with my words.
> >
> > So calculation of result type (replace ANY by some specific) can be ok?
> >
> > I am able to do it if there will be a agreement.
> ...
>
> Hi Pavel,
>
> I see that this is an active project with an ongoing discussion, but
> we have run out of July so I have moved this to the September CF and
> set it to "Waiting on Author".
>

sure

Pavel

> --
> Thomas Munro
> https://enterprisedb.com
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-08-07 06:03:36 Re: POC: Cleaning up orphaned files using undo logs
Previous Message Amit Langote 2019-08-07 05:51:45 Re: no default hash partition