Re: Support for %TYPE in CREATE FUNCTION

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