On Tue, Oct 27, 2009 at 9:20 PM, David Fetter <da...@fetter.org> wrote: > On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote: >> Robert Haas <robertmh...@gmail.com> writes: >> > I confess that I'm a bit mystified about the design of the >> > reloptions stuff. It seems kind of odd to store structured data as >> > text[]; it's kind of the opposite of what I would normally >> > recommend as good database design. >> >> It's definitely a bit EAV-ish :-(. But I don't see any particularly >> easy way to modify it to store bool/int/float parameters in their >> native types; do you? > > More columns, each of the correct type, with the table constraint that > at most one may be populated is how I handle stuff like that.
I don't see why we'd need to constrain more than one from being populated, but yeah, that's basically what I was thinking: one column per parameter, of the appropriate type. That might not be such a good model if the number of possible options was really large, but at this point there's no reason to believe that will be the case for either reloptions or the proposed spcoptions. For things like autovacuum options, the actual representation probably doesn't matter much because I'm guessing that the amount of work being done by vacuum dwarfs the parsing cost, and it's a background task anyway. But this seems like a less solid argument for things like fillfactor and the proposed per-tablespace seq_page_cost/random_page_cost, which will be accessed by many queries and in the latter case often more than once. Ideally (or so it seems to me) you'd like to fetch those things out of Form_pg_whatever rather than parsing text strings to get at 'em. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
