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 200105311415.f4VEFIn06630@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  (Pascal Scheffers <pascal@scheffers.net>)
List pgsql-hackers
Ian Lance Taylor wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> > Ian Lance Taylor <ian@airs.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.
   Indeed.

> 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
againwe   have to think about "imperfect features" as well, and looking   at  the  past (foreign key, PL/pgSQL itself
andlztext - just   to blame myself) I realize that I've not been that much of  a   perfectionist I claim to be in
recentposts.
 
   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.
Sincewe know   that doing a halfhearted tracking could severely break  other   things,  it's  out  of discussion. So
thequestion 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
andwill currently NOT follow later changes to x   should do it.
 


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: Imperfect solutions
Next
From: Bruce Momjian
Date:
Subject: Re: Imperfect solutions