Re: Elocution

Changing the topic here, you touched on another point that I think could
use some refinement. I've always thought that not enough emphasis gets
placed on stored procedures and postgres's approach to them. I hear a
lot of talk about ref. integrity, business rules, and the like (and ansi
compliance, personally, I could give a hoot about that). SP's and their
ability to be run both inside and outside of a query are whats going to
define postgres's rule in a increasingly .net dominated database world
(in win32).

Ado.net plays the lowest common denominator of database feature sets and
moves all real work to the middleware level. SPs are a way of stealing
a little bit of that thunder back, and giving the database a little
glory. (Ado.net also has a very elegant for writing high performance
drivers for 3rd party databases, so is a natural fit for pg).

Case in point: I worked on a GIS application and loved how I could
integrate our library of C and assembler code (like great circle
distance algorithm) into sp's so these functions could be utilized
THROUGH the query at the set based level, instead of lame, slow, error
prone filtering at the middleware level. Its no accident PostGIS is not
called 'MyGIS' :) This means my datasets are properly calculated and
filtered before getting bogged down by xml conversions and other cruft
like that.

According to me, SPs and server-side programming interfaces are why
postgres will be the open source database of choice. (even more
important is the liberal licensing)
Ref. Int. is nice, but you are competing with middleware technologies in
that respect.
As for ANSI compliance, well let's just say I've never read an ansi
standard, and don't plan to :). (It really is very important, I'm just
being trite).

Note: this also goes for views, but the last time I checked (7.1.3),
views did not optimize the where condition on the view through the
static query, which made them impractical for large datasets. Still,
something is better than nothing.

Merlin

-----Original Message-----
From: Jason Hihn [mailto:jhihn(at)paytimepayroll(dot)com]
Sent: Tuesday, December 10, 2002 2:12 PM
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: [pgsql-advocacy] Elocution

>Even though you could use MySQL in the same way, (putting trigger logic
in
>the app) one problem is that if you have multiple clients, all clients
must
>be upgraded lest one put your data asunder. By developing business
rules >and
>following them, you only need to update the clients when the business
logic
>changes. Other times that enhancements are made, they are made in 1
place,
>and all others get the updates intrinsically, instantly. That is
another >FUD
>item.