Re: Support for %TYPE in CREATE FUNCTION

Ian Lance Taylor wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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. It get's
called at CREATE/DROP FUNCTION and any other catalog change -
right? And the backend loads all declared procedural language
handlers at startup time so they can register themself for
callback - right? Sound's more like a 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 function in the
PL handler doing all the job? Of course, one language might,
while another uses the backward compatibility mode of the
existing CREATE FUNCTION - that's neat. And since the general
schema change callback informs one 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 gets confused.

> 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't do it. A change
like %TYPE support is a little too fundamental to get this
quick yes/no decision just in a few days.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com