Re: Extended customizing, SQL functions,

From: Shridhar Daithankar <shridhar(at)frodo(dot)hserus(dot)net>
To: pgsql(at)mohawksoft(dot)com
Cc: "Bruno Wolff III" <bruno(at)wolff(dot)to>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extended customizing, SQL functions,
Date: 2004-05-29 09:16:59
Message-ID: 200405291446.59388.shridhar@frodo.hserus.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday 29 May 2004 04:38, pgsql(at)mohawksoft(dot)com wrote:
> Now, I could roll my own system pretty easily, and probably will do so. It
> won't take too much, however, it would be neat if this was in PostgreSQL.
>
> I fully expect that people would worry about this, and I don't blame them.
> It is a *bad* idea. Like I said, I could roll my own, but I'm curious if
> anyone else sees any benefit to this feature. If it is a feature that
> people want, it would best be done from within PostgreSQL. If it is not
> something generally wanted, then I'll keep it here or try to get it on
> gborg or pgfoundary.

I agree that it could be a nice feature. But it reminds me a quote from a C++
FAQ I read once.

----------
*. Should I use exception for error handling?

Ans. The real question is can I afford stack unwinding here...
----------

The situation is similar here. When you want something in database, one
question is to ask is do I need MVCC here?

Of course depending upon the application context the answer well could be yes.
But at a lot of places, this could be easily be managed in application and
probably better be done so.

Personally I do not think managing such information in application is an
hack.

Just a thought...

Shridhar

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Hallgren 2004-05-29 09:41:29 dynamic_library_path on Win32
Previous Message Tom Lane 2004-05-29 06:09:58 Re: Win32, PITR, nested transactions, tablespaces