From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | nconway(at)klamath(dot)dyndns(dot)org (Neil Conway) |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: preserving statistics settings |
Date: | 2002-07-19 17:28:29 |
Message-ID: | 13879.1027099709@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
nconway(at)klamath(dot)dyndns(dot)org (Neil Conway) writes:
> Hmmm... we could allow SET STATISTICS to take 'DEFAULT' easily enough
> (and that might even be a good idea in any case), but you're right --
> without a way for pg_dump to determine the default value and/or whether
> the admin have explicitely changed the attstattarget for that column,
> there's not much that can be done...
> I suppose we could hard-code the current default value into pg_dump,
> but that's pretty ugly.
Also, there's no guarantee that pg_dump would know what default the
backend had been compiled with, so it might make the wrong conclusion
anyway.
> Does anyone have a better suggestion?
Not sure why I didn't think of this before, but we could make the stored
value of attstattarget be "-1" to indicate "use the default". Zero or a
positive value then indicates an explicit selection. We can't
retroactively fix 7.2, but going forward we'd have a reasonable answer.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alessandro Baretta | 2002-07-19 19:23:45 | Arrays and FFTW |
Previous Message | Barry Lind | 2002-07-19 17:03:04 | Re: heap_delete, heap_mark4update must reset t_ctid |