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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
