From: | Ian Lance Taylor <ian(at)airs(dot)com> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Support for %TYPE in CREATE FUNCTION |
Date: | 2001-05-30 20:13:44 |
Message-ID: | siwv6ywq6f.fsf@daffy.airs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-05-30 20:16:24 | Re: AW: AW: Plans for solving the VACUUM problem |
Previous Message | Jan Wieck | 2001-05-30 20:09:57 | Re: PL/pgSQL CURSOR support |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-05-30 20:52:03 | Re: [HACKERS] #ifdef OLD_FILE_NAMING |
Previous Message | Jan Wieck | 2001-05-30 20:00:00 | Re: Support for %TYPE in CREATE FUNCTION |