Re: proposal: auxiliary functions for record type

On Dec12, 2010, at 00:19 , Pavel Stehule wrote:
> I prefer a table based
> solution, because I don't need a one "unnest", but other preferences
> are valid too.
That's fine with me.

> I dissatisfied with your design of explicit target type
> via unused value. I think, so we are not a infrastructure for it now
> - from my view is better to use a common type, that is text now. It's
> nothing new - plpgsql use it too.
Sorry, I can't follow you here. Where does plpgsql use text as "common" type?

> I see one well design of explicit target type based on polymorphic
> types that respect a PostgreSQL fmgr practice:
>
> We have to allow a polymorphic functions without polymorphic
> parameters. These functions shoud be designed to return value in
> "unknown" type format when this function has not outer information.
I don't think "unknown" is the right type for that. As far as I known, "unknown" is still a textual type, used to have some type to assign to string literals during parsing when no better type can be inferred.

> This information can be passed in function context. When function
> context isn't null, then function has to read target type and should
> to return value in target type. Who can fill a function context? It is
> task for executor. And when CAST contains just function call, then we
> can recheck, if function is polymorphic, and if it is, then we can set
> function context to target type, and then we don't need to call a
> conversion function, because polymorphic function must returns data in
> correct format.
The main difficulty is that currently types are assigned in a bottom-up fashion as far as I know. To make functions with a polymorphic return value, but without polymorphic arguments work, you need to assign the return type in a top-down fashion (It depends on where to value *goes*, not where it *comes from*). That seems like a rather huge change and has the potential to complicate quite a few other parts, most notably function lookup/resolution.

Plus, the general case where type information must bubble up more than one level seems pretty much intractable, as it'd require a full-blown type inference algorithm like ML or Haskell. Not a place where we want to go, I believe.

The restricted case, on the other hand, brings very little benefit compared to the dummy-parameter approach. Yeah, "<polymorphic function>()::type" may look a bit cleaner than "<polymorphic function>(NULL::type)", but thats about is. It's only assignments in pl/pgsql which really benefit, since you'd be able to leave out the type completely, writing simply "v_value := <polymorphic_function>()". Does that really warrant the effort that'd be involved?

> Without described functionality we can design a not polymorphic
> function, that can returns unknown type. When similar functionality
> will be implemented, then this function will be changed to
> polymorphic, but from user's perspective, there isn't a change.
I don't really understand why you resist the idea of a dummy parameter so much. It might not be pretty, but is it bad enough to rectify putting in all this work? Plus, the whole record-manipulation stuff isn't going to win a beauty contest anytime soon. But it's better than nothing, so as long as it's reasonably efficient I think one can live with a few warts on the API.

best regards,
Florian Pflug