Re: Support for %TYPE in CREATE FUNCTION - Mailing list pgsql-hackers

From Ian Lance Taylor
Subject Re: Support for %TYPE in CREATE FUNCTION
Date
Msg-id siwv6ywq6f.fsf@daffy.airs.com
Whole thread Raw
In response to Re: Support for %TYPE in CREATE FUNCTION  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: Support for %TYPE in CREATE FUNCTION  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
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.

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.

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.

> > If you agree with me on the meta-point, then this is just a quibble
> > about my original patch (which made choice 1 above).  If you disagree
> > with me, I'd like to understand why.
> 
>     The  possible SIGSEGV above. Please don't take it personally,
>     I'm talking tech here, but it seems you forgot that  PL/pgSQL
>     is just *one* of many possible languages.

Actually, I don't see this as a disagreement about my meta-point.
Users who use %TYPE must watch out if they change a table definition.
A SIGSEGV is just an extreme case.

>     And  please  forget  about  a  chance  to  finally  track all
>     dependencies. You'll never be able to know if some PL/Tcl  or
>     PL/Python function/trigger uses that function. So not getting
>     your NOTICE doesn't tell if really nothing broke. As soon  as
>     you  tell  me  you  can I'd implement PL/Forth or PL/Pascal -
>     maybe PL/COBOL or PL/RPL (using an  embedded  HP48  emulator)
>     just to tell "you can't" again :-)

I don't entirely understand this.  I can break the system just as
easily using DROP FUNCTION.  At some point, I think the programmer has
to take responsibility.


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.

Ian


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PL/pgSQL CURSOR support
Next
From: Bruce Momjian
Date:
Subject: Re: AW: AW: Plans for solving the VACUUM problem