Re: Support for %TYPE in CREATE FUNCTION

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Ian Lance Taylor <ian(at)airs(dot)com>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 21:02:44
Message-ID: 200105302102.f4UL2i608063@jupiter.us.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Ian Lance Taylor wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>
> > 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.
>
> Can you explain how an external preprocessor/script addresses the
> issue of %TYPE in a function definition? Presumably the preprocessor
> has to translate %TYPE into some definite type when it creates the
> function. But how can a preprocessor address the issue of what to do
> when the table definition changes? There still has to be an entry in
> pg_proc for the procedure. What happens to that entry when the table
> changes?
>
> You seem to be saying that %TYPE can be implemented via some other
> mechanism. That is fine with me, but how would that other mechanism
> work? Why it would not raise the exact same set of issues?

What I (wanted to have) said is that the "one-time porting"
can be solved by external preprocessing/translation of %TYPE
into the resolved type at porting time. That is *porting*
instead of making the target system emulate the original
platform. You know, today you can run a mainframe application
on an Intel architecture by running IBM's OS390 emulator
under Linux - but is that porting?

And I repeat what I've allways said over the past years. I
don't feel the need for all the catalog mucking with most of
the ALTER commands. Changing column types here and there,
dropping and renaming columns and tables somewhere else and
kicking the entire schema while holding data around during
application coding doesn't have anything to do with
development or software engineering. It's pure script-kiddy
hacking or even worse quality. There seems to be no business
process description, no data model or any other "plan", just
this "let's code around until something seems to work all of
the sudden". Where's the problem description, application
spec, all the stuff the DB schema resulted from? Oh - it
resulted from "I need another column because I have this
unexpected value I need to keep - and if there'll be more of
them I can ALTER it to be an array". Well, if that's what
people consider "development", all they really need is

ALTER n% OF SCHEMA AT RANDOM;

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Paulo Angelo 2001-05-30 21:07:26 Sync Data
Previous Message Bruce Momjian 2001-05-30 20:52:03 Re: [HACKERS] #ifdef OLD_FILE_NAMING

Browse pgsql-patches by date

  From Date Subject
Next Message Ian Lance Taylor 2001-05-30 21:22:38 Re: Support for %TYPE in CREATE FUNCTION
Previous Message Bruce Momjian 2001-05-30 20:52:03 Re: [HACKERS] #ifdef OLD_FILE_NAMING