On Mon, Jan 4, 2010 at 10:42 AM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Robert Haas escribió: > >> Hmm, I see this needs to be rebased over Tom's latest changes, but the >> conflict I got was in syscache.h, rather than syscache.c. Not sure if >> that's what you were going for or if there's another issue. Updated >> patch attached. > > FWIW I think the reloptions code in this patch is sane enough. The fact > that it was this easily written means that the API for reloptions was > reasonably chosen, thanks :-)
:-) Actually, there are some things about it that I'm not entirely happy with, but I haven't brought them up because I don't have a clear idea what I think we should do about them. The special-case hack to handle the "oids" option is one of them.... another, possibly related, is that I wish we could decouple the options-validation logic from the backend storage representation. But those are issues for a future thread. I do think it's pretty well-done overall. > Hmm, it seems we're missing a "need_initialization = false" at the > bottom of initialize_reloptions ... I'm wondering what happened to > that?? It appears that it has never been there. $ git log -Sneed_initialization master src/backend/access/common/reloptions.c commit f35e4442a6c9893e72fe870d9e1756262d542027 Author: Alvaro Herrera <alvhe...@alvh.no-ip.org> Date: Mon Jan 5 17:14:28 2009 +0000 Change the reloptions machinery to use a table-based parser, and provide a more complete framework for writing custom option processing routines by user-defined access methods. Catalog version bumped due to the general API changes, which are going to affect user-defined "amoptions" routines. That was the original patch that added need_initialization, and it didn't add that line. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers