Re: WIP: guc enums - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: WIP: guc enums
Date
Msg-id 20080305095313.GE5559@svr2.hagander.net
Whole thread Raw
In response to Re: WIP: guc enums  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-patches
On Tue, Mar 04, 2008 at 09:35:27PM +0000, Heikki Linnakangas wrote:
>
> We could keep using the assignment hooks. But they could be a lot
> simpler than they are nowadays, if the string -> int conversion was done
> by the GUC machinery:
>
> static const char *
> assign_client_min_messages(int newval, bool doit, GucSource source)
> {
>     client_min_messages = newval;
> }

That would work. We'd need to keep the dummy variable as well, and point to
that one (since we need a place for guc to store it).

Toms suggested method obviously works as well, takes less code, but does
have those other drawbacks you mentioned (compiler checks off). I can try
either way depending on what people prefer :-)

> Another idea would be cajole the compiler to choose a type of the same
> length as "int", by adding a dummy enum value to the enum, like:
>
> enum client_min_messages {
>   DEBUG,
>   INFO,
>   ...,
>   DUMMY = INT_MAX
> }
>
> Though I guess it might in theory choose something even wider, and the
> "*((int *)enumptr) = x" would fail to set all the bits of the enum variable.

This seems like a bad choice to me.


> BTW, shouldn't be using malloc in config_enum_get_options...

Ah, that's indeed wrong. Originally I used it only for the hint message,
which is explicitly free()d later... But now it needs a palloc, yes. Fixed.

//Magnus

pgsql-patches by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: WIP: guc enums
Next
From: Tom Lane
Date:
Subject: Re: WIP: guc enums