Re: A different approach to extension NO USER DATA feature - Mailing list pgsql-hackers

From Robert Haas
Subject Re: A different approach to extension NO USER DATA feature
Date
Msg-id AANLkTiknqAc-nug4-HHNRurgH3LouUOLPYLTaejwjd+o@mail.gmail.com
Whole thread Raw
In response to Re: A different approach to extension NO USER DATA feature  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: A different approach to extension NO USER DATA feature
List pgsql-hackers
On Mon, Feb 7, 2011 at 4:18 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Or do you want to keep some generality here?

I think it might be slightly advantageous to keep some generality,
because some people might already have catalog columns that do this
(but with a different name) or might have other reasons for needing an
integer "entry type" column from which the system property can be
inferred.  I can't think how many times I've written a web interface
that lets users edit a foo, but denies them the ability to edit any
foo where bar_id = 1 (because those are the magic ones that get
created some other way).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: strk
Date:
Subject: Re: DROP SCHEMA xxx CASCADE: ERROR: could not open relation with OID yyy
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: remove tags.