Simon Riggs wrote:
> On Wed, 2007-04-04 at 16:26 -0400, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > Simon Riggs wrote:
> > >> Having both default GUC and individual table-level WITH parameters seems
> > >> like the best way to me.
> >
> > > Agreed.
> >
> > There's an extremely good reason not to have a GUC variable, which is
> > that changes in it would fail to reflect into decisions about whether to
> > create TOAST tables. When I first brought up the point I didn't see a
> > way around it, but now that I do, I don't think we should expose a
> > failure mode just to have a GUC.
>
> It depends how it works. If the GUC was a default that was applied only
> at CREATE TABLE time, then it would be safe.
Well, if the GUC applies at CREATE TABLE, it is storing the GUC in
pg_class, which was my point.
> Changing default_with_oids didn't cause all tables to stop/start using
> oids. Why would it?
oid status is stored in pg_class.
> > > OK, but we need to throw a clear message when the TOAST table needs to
> > > be created by the administrator.
> >
> > No, we just need to not have a GUC for this. There's no GUC for default
> > fill factor; have you seen anyone complain about that?
>
> I'd rather set it once than many times, thats all.
Let's find the optimal value for the default, and then you use that all
the time and just change it when you want to when you create the column.
> I certainly care more about temp_tablespaces than I do about this GUC...
> that is something I'll be moaning about if that gets deferred.
I don't see how they are related.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
