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

Tom Lane wrote:
> Ian Lance Taylor <ian@airs.com> writes:
> > I have a meta-point: the choices to be made here are not all that
> > interesting.  They do have to be defined.  But almost any definition
> > is OK.
>
> Well, that implicit assumption is exactly the one I was questioning;
> *is* it OK not to be very concerned about what the behavior is?  ISTM
> that how the system handles these cases will constrain the use of the
> %TYPE feature into certain pathways.  The limitations arising from your
> original patch presumably don't matter for your intended use, but they
> may nonetheless be surprising for people who try to use it differently.
> (We've seen cases before where someone does a quick-and-dirty feature
> addition that fails to act as other people expect it to.)
   IMHO  the possible confusion added by supporting %TYPE in our   utility statements is too high a risk.
   What most of those if favor for doing it right now want is an   easy  Oracle->PostgreSQL  one-time  porting path.
Reasonable,  but solveable with some external preprocessor/script too.
 
   I see that the currently discussed implementation add's  more   Oracle  incompatibility  than  compatibility. This
isbecause   there are different times between the interpretation of %TYPE   inside  and  out  of  a  procedures body.
Insidethe PL/pgSQL   declarations, it's parsed at each first call  of  a  function   per  session,  so  there is at
leastsome chance that changes   propagate up (at reconnect time).
 
   But used in  the  utility  statement  to  specify  arguments,   column  types and the like they are interpreted just
onceand   stored as  that  in  our  catalog.   We  don't  remember  the   original  CREATE  statement,  that  created
it.So even if we   remember that this thing once depended on another,  we  don't   know what to do if that other is
altered.
   Thus,  usage  of  %TYPE  inside of a PL/pgSQL function is OK,   because it behaves more or less  like  expected  -
at least   after  reconnecting. Using it outside IMHO isn't, because the   type reference cannot be  stored  as  that,
but has  to  be   resolved  once and forever with possible code breakage if the   referenced objects type changes.  The
kindof breakage  could   be  extremely  tricky  and  the code might appear to work but   does the wrong  thing
internally (think  about  changing  a   column  from  DOUBLE  to NUMERIC and assuming that everything   working with
thiscolumn is doing exact precision from now on   - it might NOT).
 
   A "No" from here.


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