Re: Avoiding Application Re-test - Mailing list pgsql-hackers

From Asko Oja
Subject Re: Avoiding Application Re-test
Date
Msg-id ecd779860808070947g124578b6s9894e782e47b73b5@mail.gmail.com
Whole thread Raw
In response to Avoiding Application Re-test  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
It would make PostgreSQL too much like Oracle ;) Let's keep PostgreSQL simple and compact please.
I prefer applications retest when migrating to new PostgreSQL version. In this case surprises happen then you expect them not in some unforeseen point of time in the future.
Keeping all this old functionality around will make maintenance and adding new stuff harder.
It also complicates tracking problems where in addition to db version you need to find out what version it is supposed to emulate.

On Thu, Aug 7, 2008 at 5:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
Tom's recent changes to allow hash distinct (yay!) prompted something
that I'd thought about previously.

Subtle changes in the output of queries can force an application retest,
which then can slow down or prevent an upgrade to the latest release. We
always assume the upgrade itself is the problem, but the biggest barrier
I see is the cost and delay involved in upgrading the application.

We could invent a new parameter called enable_sort_distinct, but thats
way too specific and horrible.

What I would like is a parameter called sql_compatibility which has
settings such as 8.3, 8.4 etc.. By default it would have the value 8.4,
but for people that want to upgrade *without* retesting their
application, they could set it to 8.3.

Every time we introduce a feature that changes output, we just put an if
test in saying sql_compatibility = X, (the release we added feature).

Straightforward, futureproof. Cool.

Not foolproof, but still worth it. This would allow many users to
upgrade to 8.4 for new features, yet without changing apps.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Visibility Groups
Next
From: "David E. Wheeler"
Date:
Subject: Re: patch: Add columns via CREATE OR REPLACE VIEW