Re: Support for %TYPE in CREATE FUNCTION

Jan Wieck <janwieck@yahoo.com>

From: Jan Wieck <JanWieck@Yahoo.com>
To: Ian Lance Taylor <ian@airs.com>
Cc: Jan Wieck <JanWieck@Yahoo.com>, Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Date: 2001-05-30T22:00:05Z
Lists: 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. 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@Yahoo.com #



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