Re: Extended customizing, SQL functions, - Mailing list pgsql-hackers

From Shridhar Daithankar
Subject Re: Extended customizing, SQL functions,
Date
Msg-id 200405291446.59388.shridhar@frodo.hserus.net
Whole thread Raw
In response to Re: Extended customizing, SQL functions,  (pgsql@mohawksoft.com)
Responses Re: Extended customizing, SQL functions,  (pgsql@mohawksoft.com)
List pgsql-hackers
On Saturday 29 May 2004 04:38, pgsql@mohawksoft.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


pgsql-hackers by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: temp tables broken in CVS HEAD?
Next
From: "Thomas Hallgren"
Date:
Subject: dynamic_library_path on Win32