Re: Per-database/schema settings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Per-database/schema settings
Date: 2000-07-05 06:42:41
Message-ID: 766.962779361@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> My initial thought was to add columns to
> pg_database for each setting, but this is not very extensible. Another
> possibility might be to add routines somewhere as "trigger-able events"
> which happen when, say, a row is selected from pg_database. I'll guess
> that this in particular won't work, since pg_database is not opened from
> within a fully functioning Postgres backend.

IIRC, pg_database is rechecked as soon as a new backend is up and
running. So it'd be easy enough to extract additional values from
the pg_database row at that instant. A trigger wouldn't help though,
it'd have to be hardwired code. (Even if we tweaked the backend to
fire a trigger at that point, where would the trigger get the data
from? You'd still need to add columns to pg_database.)

I agree that adding columns to pg_database is a painful way of creating
per-database options, but I'm not sure what would be better.

> Any thoughts on how to go about this? I assume that Peter's recent
> "options" work does not apply, since it is not directly accessible
> though SQL. But I haven't looked to verify this assumption.

AFAIR his options stuff does not support per-database settings.
But perhaps it could be made to do so ... Peter, any thoughts?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-07-05 07:11:07 RE: current CVS: undefined reference to `PGLZ_RAW_SIZE'
Previous Message Tim Perdue 2000-07-05 06:40:44 Re: Article on MySQL vs. Postgres