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:

Previous
From: Ian Lance Taylor
Date:
Subject: Re: Support for %TYPE in CREATE FUNCTION
Next
From: Bruce Momjian
Date:
Subject: Re: Support for %TYPE in CREATE FUNCTION