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: 200105311415.f4VEFIn06630@jupiter.us.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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.

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 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.

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 djohnson 2001-05-31 14:34:27 Re:Sync Data
Previous Message Tom Lane 2001-05-31 14:07:36 Re: Imperfect solutions

Browse pgsql-patches by date

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