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