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 200105302102.f4UL2i608063@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
List pgsql-hackers
Ian Lance Taylor wrote:
> Jan Wieck <JanWieck@Yahoo.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
codearound 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'swhat   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@Yahoo.com #



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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: First version of multi-key index support for GiST
Next
From: Paulo Angelo
Date:
Subject: Sync Data