* Stephen Frost (sfr...@snowman.net) wrote:
> I have a feeling that much of the GUC machinery could be reworked; as
> Jim mentioned up-thread, it might be possible to use memory contexts too
> which would make a lot of it much cleaner, I believe.
Err, "on another thread", not on this one. :)
And
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > I think the code is OK, but yeah, this comment should be changed to
> > > reflect the idea that the function will append entries to an existing
> > > list of name/value pairs (
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > I think the code is OK, but yeah, this comment should be changed to
> > reflect the idea that the function will append entries to an existing
> > list of name/value pairs (and thus, that head_p/tail_p are not output
> > but in/out pa
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think the code is OK, but yeah, this comment should be changed to
> reflect the idea that the function will append entries to an existing
> list of name/value pairs (and thus, that head_p/tail_p are not output
> but in/out parameters).
I've pushed a fix f
Stephen Frost writes:
> Greetings,
> While working through the pg_file_settings patch, I came across this
> comment above ParseConfigFp() (which is called by ParseConfigFile()):
> src/backend/utils/misc/guc-file.l:603
> --
> * Output parame
Greetings,
While working through the pg_file_settings patch, I came across this
comment above ParseConfigFp() (which is called by ParseConfigFile()):
src/backend/utils/misc/guc-file.l:603
--
* Output parameters:
* head_p, tail_p: head and
