Re: Extended customizing, SQL functions, - Mailing 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?

I am a HUGE C/C++ guy. A lot of people dump on C++ because it lets you
shoot yourself in the foot with both barrels without even knowing how ...
if you are not careful. Oddly enough, this very flexability is what makes
it a very powerful and useful language.

Similarly, sometimes, it is very difficult to make PostgreSQL do some of
the things that you need too.


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


I may have a unique view of PostgreSQL, but I don't think of it as just a
database. I think of it as a great applications platform. Most
applications today are data centric, and postgresql fits this bill
perfectly. As a data layer it is hard to beat. The fact that it is a great
SQL database in its own right, is a huge bonus. That being said, every now
and then it lacks this small little feature that working around takes a
bit of work. Like functions returning multiple results, that was huge.
Functions returning rows, that was huge too.

Having internal PostgreSQL variables that are not present on disk, or
maybe, variables that are mirrored on disk may be good.

The whole reason why I made this post was to see if other people have had
similar issues and looked for a similar solution, and to think about if
there is a solution that fits within PostgreSQL and how it would work.