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
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 |