Re: Support for %TYPE in CREATE FUNCTION - Mailing list pgsql-hackers
From | Jan Wieck |
---|---|
Subject | Re: Support for %TYPE in CREATE FUNCTION |
Date | |
Msg-id | 200105302200.f4UM05r08147@jupiter.us.greatbridge.com Whole thread Raw |
In response to | Re: Support for %TYPE in CREATE FUNCTION (Ian Lance Taylor <ian@airs.com>) |
Responses |
Re: Support for %TYPE in CREATE FUNCTION
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Support for %TYPE in CREATE FUNCTION (Ian Lance Taylor <ian@airs.com>) |
List | pgsql-hackers |
Ian Lance Taylor wrote: > Jan Wieck <JanWieck@Yahoo.com> writes: > > > Altering a function definition in any language other than > > PL/pgSQL really scares me. What do you expect a "C" function > > declared to take a VARCHAR argument to do if you just change > > the pg_proc entry telling it now takes a NAME? I'd expect it > > to generate a signal 11 most of it's calls, and nothing > > really useful the other times. > > Good point. > > That brings me back to choice 1 in my original message: don't try to > change the function if the table definition changes. > > In fact, it's possible to do better. A procedural language could > define a hook to handle table definition changes. The Postgres > backend could define a way to register to receive notification of > table definition changes (this would essentially be an entry in a > table like the proposed pg_depends). The procedural language itself > could then handle the table changes by redefining the function or > whatever. > > When defining a function using %TYPE, the procedural language would be > notified that %TYPE was used. It could then record a dependency, if > it was prepared to handle one. When defining a function, there is absolutely no language dependant code invoked (except for 'sql'). So at the time you do the CREATE FUNCTION, the PL/pgSQL handler doesn't even get loaded. All the utility does is creating the pg_proc entry. When the analyzis of a query results in this pg_proc entries oid to appear in a Func node and that Func node get's hit during the queries execution, then the function manager will load the PL handler and call it. What you describe above is a general schema change callback entry point into a procedural language module. Itget's called at CREATE/DROP FUNCTION and any other catalog change - right? And the backend loads all declared procedurallanguage handlers at startup time so they can register themself for callback - right? Sound's more likea bigger project than a small grammar change. > This would permit PL/pgSQL to redefine the function defined using > %TYPE if that seems desirable. It would also permit PL/pgSQL to > behave more reasonably with regard to variables defined using %TYPE. Ah - so the CREATE FUNCTION utility doesn't create the pg_proc entry any more, but just calls some functionin the PL handler doing all the job? Of course, one language might, while another uses the backward compatibilitymode of the existing CREATE FUNCTION - that's neat. And since the general schema change callback informsone PL (the one that want's to get informed), every language could decide on it's own if it's better to create another overload function, drop the existing, modify the existing or just abort the transaction if it getsconfused. > This would also permit the C function handler to issue a NOTICE when a > C function was defined using %TYPE and the table definition was > changed. Seems I missed some code changes in the past, so where's this new C function handler located and how does it work? > I return to the question of whether the Postgres development team is > interested in support for %TYPE. If the team is not interested, then > I'm wasting my time. I'm seeing a no from you and Tom Lane, and a > maybe from Bruce Momjian. I don't say we shouldn't have support for %TYPE. But if we have it, ppl will assume it tracks later schema changes,but with what I've seen so far it either could have severe side effects on other languages or just doesn'tdo it. A change like %TYPE support is a little too fundamental to get this quick yes/no decision just in afew days. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
pgsql-hackers by date: