0

Say we have an SQL database with a table Person and several applications accessing it. For some reason we would like to modify the Person table in a backward-incompatible way.

One potential solution for keeping compatibility is to rename the table to User and to create a Person view that provides the same interface as the legacy table. (Add on insert, on update and on delete triggers as needed).

The approach has the problem that we might run out of available semantically correct names after a few changes.

Is there a well-known best practice for "namespacing" the schema "interface" according to the DB version?

Alternatively, is there a better way to maintain backward-compatibility?

4

1 回答 1

1

Is there a well-known best practice for "namespacing" the schema "interface" according to the DB version?

It's not a common requirement, but when I've seen the need for similar things I've tended to create a new schema that contains the backwards-compatible wrapper for the table in a separate schema (namespace). I then set the search_path on a per-user basis so that the user who needs the backward compat table sees it, and the others see the new version.

The BC view has a RULE or (in newer PostgreSQL versions) a DO INSTEAD trigger referring to the current version of the table explicitly from its normal schema, eg public.People, to support writes if required.

This only works if you need BC on a per-login-user basis where you can ALTER USER ... SET search_path, or (less likely) where you can set the application that needs BC to run a SET search_path command on each session.

于 2013-07-18T07:52:43.740 回答