Skip site navigation (1) Skip section navigation (2)

Re: Support for %TYPE in CREATE FUNCTION

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ian Lance Taylor <ian(at)airs(dot)com>, 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 18:39:26
Message-ID: 200105301839.f4UIdQX07733@jupiter.us.greatbridge.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Ian Lance Taylor <ian(at)airs(dot)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 is because
    there are different times between the interpretation of %TYPE
    inside  and  out  of  a  procedures body. Inside the PL/pgSQL
    declarations, it's parsed at each first call  of  a  function
    per  session,  so  there is at least some 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 once and
    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 kind of 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 this column 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(at)Yahoo(dot)com #



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


In response to

Responses

pgsql-hackers by date

Next:From: Jan WieckDate: 2001-05-30 19:11:48
Subject: Re: Cache for query plans
Previous:From: D. HagemanDate: 2001-05-30 18:33:33
Subject: Re: PL/pgSQL CURSOR support

pgsql-patches by date

Next:From: The Hermit HackerDate: 2001-05-30 19:21:38
Subject: Re: Patch to remove sort files, temp tables, unreferenced files
Previous:From: Bruce MomjianDate: 2001-05-30 18:21:58
Subject: Re: Patch to remove sort files, temp tables, unreferenced files

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group