Re: Design Strategy WAS: High-Profile Advocacy - Mailing list pgsql-advocacy

From Rod Taylor
Subject Re: Design Strategy WAS: High-Profile Advocacy
Date
Msg-id 1088104097.95078.889.camel@jester
Whole thread Raw
In response to Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum  ("Thomas Hallgren" <thhal@mailblocks.com>)
Responses Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum  (Thomas Hallgren <thhal@mailblocks.com>)
List 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.



pgsql-advocacy by date:

Previous
From: "Thomas Hallgren"
Date:
Subject: Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum
Next
From: Thomas Hallgren
Date:
Subject: Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum