On Mon, 2006-11-06 at 09:02 +0000, Dave Page wrote:
> Neil Conway wrote:
> > On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
> >> Nothing except initdb should add objects in pg_catalog. AFAICS,
> >> adminpack doesn't have any special requirements, so it should behave
> >> like all other contrib modules.
> >
> > Where are we on this? When this topic was last discussed, the three
> > alternatives were:
> >
> > (1) Modify contrib/adminpack to not use the pg_catalog schema,
> > per the consensus that contrib/ packages installing objects
> > into that schema is broken behavior
> >
> > (2) Don't modify contrib/adminpack, for the sake of backward
> > compatibility
> >
> > (3) Remove contrib/adminpack from the Postgres distribution
> >
> > I think the discussion was edging toward #3, but #2 is the only option
> > that I'm not happy with. Any other opinions out there?
>
> Looking back over the thread, it appears that only you and Peter
> objected to it as it is now. Tom, Andreas and myself were of the opinion
> it was fine as it is, and whilst he didn't comment on how it should be
> implemented, Simon made the point that supporting admin tools from the
> core distribution was important which I take to mean he is against #3.
Definitely against #3. [Argument: not just pgAdmin, essential feature]
At the moment we only allow 2 types of table. Approved core catalog
tables and user tables.
ISTM we need 3 types of tables, with the additional type being add-on
system functionality, such as adminpack, but also possibly including
performance logging tables, extended trace tools, security packages
(e.g. Veil) etc etc. We have made provision for user add-ons to allocate
LWlocks and shared memory, but no provision for additional tables.
Surely we must be able to accommodate things as simple as additional
tables?
So we would then have (change names as appropriate)
- core catalog
- catalog extensions
- user tables.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
