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

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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




# 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 address at

In response to


pgsql-hackers by date

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

pgsql-patches by date

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

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