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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <JanWieck(at)Yahoo(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-31 14:15:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Ian Lance Taylor wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > Ian Lance Taylor <ian(at)airs(dot)com> writes:
> > > It is desirable to have some reasonable mechanism for changing the
> > > schema without requiring data to be dumped and reloaded.  Otherwise it
> > > is very difficult to upgrade a system which needs to be up 24/7, such
> > > as many web sites today.
> >
> > > It is not acceptable for eBay to shut down their system for even just
> > > a few hours for maintenance.  Shouldn't it be possible for eBay to run
> > > on top of Postgres?
> >
> > What's that got to do with the argument at hand?  On-the-fly schema
> > changes aren't free either; at the very least you have to lock down the
> > tables involved while you change them.  When the change cascades across
> > multiple tables and functions (if it doesn't, this feature is hardly
> > of any use!), ISTM you still end up shutting down your operation for as
> > long as it takes to do the changes.
> That's a lot better than a dump and restore.


> I was just responding to Jan's comments about ALTER statements.  Jan's
> comments didn't appear to have anything to do with %TYPE, and mine
> didn't either.  Apologies if I misunderstood.

    That's  what  happens  when  ppl  run  out  of arguments, and
    developers are human beeings too - unfortunately ;-}

    I think Bruce made a point in his other tread about imperfect
    fixes.  This is of course no fix but a feature. Then again we
    have to think about "imperfect features" as well, and looking
    at  the  past (foreign key, PL/pgSQL itself and lztext - just
    to blame myself) I realize that I've not been that much of  a
    perfectionist I claim to be in recent posts.

    And  Bruce  is  right,  the  speed we demonstrated in gaining
    features wouldn't have been  possible  if  we'd  insisted  on
    perfectionism all the time like we currently seem to do.

    I  can  understand  Ian.  Working for some time on a feature,
    posting a patch and watching it going down in the  flames  of
    discussion is frustrating. Even more frustrating is it if you
    asked for discussion before and nobody  responded  with  more
    than  a  *shrug*  -  then  when  you've  done  the  work  the
    discussion starts.

    At least we know by now that we want to  have  that  feature.
    And  we  know  that we can't do it perfect now. Since we know
    that doing a halfhearted tracking could severely break  other
    things,  it's  out  of discussion. So the question we have to
    answer is if we accept the %TYPE syntax with  immediate  type
    resolution  and  delay  the  real  fix  until the FAQ's force
    someone to do it. It doesn't hurt as long as you don't use it
    AND  expect  it  to  do  more  than that.  So a NOTICE at the
    actual usage, telling that  x%TYPE  for  y  got  resolved  to
    basetype  z  and will currently NOT follow later changes to x
    should do it.



# 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: djohnsonDate: 2001-05-31 14:34:27
Subject: Re:Sync Data
Previous:From: Tom LaneDate: 2001-05-31 14:07:36
Subject: Re: Imperfect solutions

pgsql-patches by date

Next:From: Chris DunlopDate: 2001-05-31 14:54:41
Subject: Australian timezone configure option
Previous:From: Christopher Kings-LynneDate: 2001-05-31 11:03:06
Subject: DROP CONSTRAINT (UNIQUE) preliminary support

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