On Sun, Oct 25, 2009 at 9:05 AM, Robert Haas <robertmh...@gmail.com> wrote: > Arguably, you would expect parameters set using this syntax to be > stored similar to reloptions - that is, as text[]. But as we're going > to need these values multiple times per table to plan any non-trivial > query, I don't want to inject unnecessary parsing overhead and code > complexity.
Two comments, perhaps complementary, though I'm not sure of either answer. 1 Would we rather the storage scheme allow for future GUCs to be easily moved to per-tablespace as well without changing the catalog schema for every option? (Someone might accuse me of trolling the anti-EAV people here though...) 2 Would it make sense to slurp these options from the tablespace options into the relcache when building the relcache entry for a table? That would make the storage format in the tablespace options much less relevant. It might even make the catcache less important too. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
