Re: pg_guc - Mailing list pgsql-hackers

From Aizaz Ahmed
Subject Re: pg_guc
Date
Msg-id 1056738086.24597.2217.camel@toffee.toronto.redhat.com
Whole thread Raw
In response to Re: pg_guc  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2003-06-27 at 10:32, Tom Lane wrote:

> Aizaz, if you look at backend/main/main.c it should be pretty obvious
> how to handle this --- it's just like bootstrap mode.  main.c kicks off
> control to GucInfoMain or whatever we call it, and then that routine
> can act pretty much the same as if it were the actual main() of a
> standalone pg_guc.  This also eliminates the need for VARADDR() and a
> lot of the other thrashing about we were doing to allow creation of
> a standalone variable table ... in fact, I think quite a large
> percentage of the patch disappears ...

So I guess that means pg_guc should be put back in
/src/backend/utils/misc ? or is there some other directory it should be
placed in now?

What about the DESC_DETAIL macro that was used to compile a short vs
long description? Is the backend going to have the long description
compiled right into it? Will there be only one description, short or
long? (if short we can use it in SHOW, (perhaps)) or should I create an
extra field in the GUC tables for a separate long field. (you were quite
opposed to this)?

If pg_guc is going to get built with the rest of the backend, I could
avoid that code refactoring from xlog.c that I did.(the fsync flags and
the creation of the syncflag.h file). Should I include these changes to
the patch anyway?

and ... will you be around perhaps on Sunday to answer any questions
that may come up?

Thanks,
Aizaz



pgsql-hackers by date:

Previous
From: Kevin Jacobs
Date:
Subject: Re: PlPython
Next
From: Rod Taylor
Date:
Subject: 7.2 to 7.4 upgrade issues