| From: | Rod Taylor <pg(at)rbt(dot)ca> |
|---|---|
| To: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
| Cc: | Postgresql Advocacy <pgsql-advocacy(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: Design Strategy WAS: High-Profile Advocacy |
| Date: | 2004-06-24 19:08:18 |
| Message-ID: | 1088104097.95078.889.camel@jester |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-advocacy |
> Still an abstraction might be worth it for many ISV's. The refactoring you
> mention is only needed if you don't cater for the independence from the very
> start.
One of the things that PostgreSQL is nice at is the ability to write
your database procedures in the same language as your middleware in many
cases (ignore java for now).
With a little bit of abstraction around the database handle itself
(libpq vs SPI) and now you can shove the procedure into the database or
pull it back to the middware when you port to another db.
Write in such a way that you rely on database triggers or application
side triggers based on database type (easy enough).
Not perfect by any means, but certainly can make life easier.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Hallgren | 2004-06-24 19:56:16 | Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum |
| Previous Message | Thomas Hallgren | 2004-06-24 18:42:21 | Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum |