Euler Taveira de Oliveira <eu...@timbira.com> wrote:
> >> INSERT INTO dbms_stats.columns(starelid, ataattnum, stadistinct)
> >> VALUES ('tablename'::regclass, 3, 100);
> >
> > Why wouldn't you implement this through reloptions?
> >
> Because it is column-based and not table-based? In this case, we need to store
> and array value like {attnum, stadistinct}. If it is not ugly in your POV, +1
> for this approach.
Yes, column-based storage is needed. However, when we drop tables,
dangling stat settings might remain. I want core-support for the module,
for example, "TRIGGER ON DROP TABLE" or some drop-relation-hooks.
There might be another approach that we add pg_attribute.attoptions for
generic column-based options, like pg_class.reloptions.
Which approach is better, or something else?
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
