On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Robert Haas escribió: > >> I don't see anything in this code that is very rel-specific, so I >> think it would be possible to implement spcoptions by just defining >> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of >> an unsavory feeling that I'm sure someone is going to complain about >> it... I suppose we could go through and systematically rename all >> instances of reloptions to ent(ity)options or storageoptions or >> gen(eric)options or somesuch... > > Maybe I missed part of the discussion, but do these really need to be > handled like reloptions instead of like datoptions? Perhaps the > deciding factor is that we want to parse them once and store them in a > cache, so like reloptions; the others are used once per connection and > then thrown away.
This may be a stupid question, but what are datoptions? $ git grep datoptions $ > If this is the case, then I think we could just decide that their name > is reloptions due to hysterical reasons and be done with it. Yeah. It's particularly unfortunate that we call them "reloptions" in the code but "storage parameters" in the documentation. Neither is a particularly good name, and having two different ones is extra-poor. But I'm fine with leaving the names as they are and moving on, if no one objects too much. Speak now or don't complain about it after I write the patch! ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
