On Mon, 2005-02-28 at 10:13 -0700, Ken Johanson wrote: > >I'm a little worried about PostgreSQL having the same problems as PHP. > >In PHP, every time you want to download an application, you never see > >"This application works on php 4+". Instead, you see "This application > >works on php4+ with the following config options set <long list>". > >Sometimes these applications have conflicting requirements. From an > >administrator's standpoint, it's a mess. > > > >In PostgreSQL I think it would actually be much worse. Right now many > >applications build a PostgreSQL layer, but will they build two? I think > >this would cause a divide in the application support (some for config > >option A some for config option B) in the already smaller-than-we'd-like > >set of software that supports PostgreSQL. > > > >Regards, > > Jeff Davis > > > > > There's certainly two perspectives to this. The one you present is > certainly valid, but consider the bigger picture... > > "This application requires the following databases: Oracle versionX, MY > SQL version X, Mysql version 5.2 with the no-backslashes option, UltraDB > version x" > > Notice the lack of PG - [snip] A valid point: that's certainly the issue we're dealing with here. I think most people agree that being SQL compliant is good. The question is: is it worth the pain for existing users? A configurable option does not make the pain disappear. Admins are forced to choose one side (either sql compliant or c style) and exclude the other applications. Any app developer that wants to support pre-8.1 apps will have to have a c-style app available. So even if you nip it in the bud, it's not really gone yet because app developers want to support old versions of postgres. I know if we added the option and deprecated the old style, I would be forced to choose between using deprecated syntax that may not be supported for long, or doing a lot of work to convert and retest applications. > Besides, the version-deprecation / version requirements you mention > exists in every piece of software I've even seen. Sometime they're okay > with a really old version, sometime only the newest will do. This is the > very argument for getting PG to offer an (use-optional) escape behavior > inline with the rest - to mitigate these version requirements down the road. I think you may have misunderstood what I meant. I am not suggesting that we don't change the database at all between versions, my argument was showing the difficulties when one version has many different shapes due to many incompatible options. Regards, Jeff Davis ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
