Re: Extended customizing, SQL functions,
От | Shridhar Daithankar |
---|---|
Тема | Re: Extended customizing, SQL functions, |
Дата | |
Msg-id | 200405291446.59388.shridhar@frodo.hserus.net обсуждение исходный текст |
Ответ на | Re: Extended customizing, SQL functions, (pgsql@mohawksoft.com) |
Ответы |
Re: Extended customizing, SQL functions,
|
Список | 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 по дате отправления: