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
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 @yahoo.com address at http://mail.yahoo.com
In response to
pgsql-hackers by date
|Next:||From: djohnson||Date: 2001-05-31 14:34:27|
|Subject: Re:Sync Data |
|Previous:||From: Tom Lane||Date: 2001-05-31 14:07:36|
|Subject: Re: Imperfect solutions |
pgsql-patches by date
|Next:||From: Chris Dunlop||Date: 2001-05-31 14:54:41|
|Subject: Australian timezone configure option|
|Previous:||From: Christopher Kings-Lynne||Date: 2001-05-31 11:03:06|
|Subject: DROP CONSTRAINT (UNIQUE) preliminary support|