Re: WIP: Faster Expression Processing v4

On 2017-03-10 08:51:25 -0500, Peter Eisentraut wrote:
> On 3/7/17 19:14, Andres Freund wrote:
> >> Why shouldn't the function itself also depend on the components of its
> >> return type?
> > Because that'd make it impossible to change the return type components -
> > if the return type is baked into the view that's necessary, but for a
> > "freestanding function" it's not. If you e.g. have a function that just
> > returns a table's rows, it'd certainly be annoying if that'd prevent you
> > from dropping columns.
>
> I think functions breaking when the return type is fiddled with is
> actually a not-uncommon problem in practice. It would be nice if that
> could be addressed.

What problem are you thinking of exactly, and what'd be the solution?
I'd guess that people wouldn't like being unable to change columns in a
table if some function returned the type.

One rather extreme way would be to have functions return a "different"
type, that's initially identical to the table/composite type. If the
ocmposite type then changes, we'd transparently map between the actual
return type, and the one callers expect. But that'd a fair bit of
effort, and presumably also quite confusing for users that might
e.g. expect a new column to show up.

> Not necessarily in this patch, but I would like to keep the options
> open.

Yea, seems worth thinking about. I don't think the patch closes down
options?

Greetings,

Andres Freund