Steve Bergman wrote:
>On Mon, 2004-08-02 at 16:47 -0700, Jonathan Gardner wrote:
>
>
>
>>They don't need to run postgreSQL on their developer machine. Just provide
>>them with a test cluster or a developer's cluster and allow them to create
>>and administer their own databases.
>>
>>
> <>
> At work, I do run a MySQL and now also a PostgreSQL server. However,
> one of my coworkers is taken in enough with the idea of using Open
> Source tools that he wants to set up a development platform at home.
> Historically, a Windows developer, he is installing Linux there.
> However, he wants the ability to run the same stuff under Windows for
> our clients who don't use Unix or Linux.
>
Hoping we will see PostgreSQL for Win32 do really well :-)
I have been running it on Cygwin for a while. Complex to set up but
pretty stable aside from pid file issues
>
>> <>I really appreciate the great responses that I have gotten here. I have
>> ported my (rather small and simple, 1500 line, 4 tables) current project
>> to pgsql, and have already used a few pgsql features. Namely, the (more
>> flexible) unique key constraints and also views. When I decided to
>> develop the pgsql and mysql branches in tandem, I decided to guard
>> against trying to use pgsql as a mysql drop in replacement, since I knew
>> that would be unfair to pgsql. I've decided, at this point do drop
>> development on the mysql branch and just finish up the pgsql branch.
>> I'm pretty much convinced that learning pgsql is where I should put my
>> efforts. Once I've had some more time to study pgsql's capabilities,
>> I'll probably tear this project down and completely redesign it to take
>> full advantage.
>>
My lightweight wrappers are more symantic wrappers.
Also, I have concluded that the ideal database *should* allow you to
have PostgreSQL be a drop-in replacement for anything. The only
difference is that you get a number of additional features by using the
PostgreSQL version. I do this using many VIEWs which often wrap stored
procedures, etc.
Here is an example of PostgreSQL in one environment being a drop in
replacement for another.
I recently ported the application to a new environment-- one of limited
user accounts. I was able to set up a database which required modifying
only *one* function in my code to make it work. The solution made
extensive use of views, stored procs, and triggers to enforce
permissions on a per-session app-authenticated level rather than the
per-session db authenticated way that is usual.
You can ALWAYS wrap stored procs into views to create extremely
sophisticated databases.
Best Wishes,
Chris Travers
Metatron Technology Consulting
