Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > I guess I'm still wondering which part of this actually needs to be
> > hand-coded so that it can be flexible. I'm envisioning the whole
> > loop replaced by something like
> >
> > FillRelOptions((void *) rdopts, options, &constanttable);
> >
>
Tom Lane wrote:
> I guess I'm still wondering which part of this actually needs to be
> hand-coded so that it can be flexible. I'm envisioning the whole
> loop replaced by something like
>
> FillRelOptions((void *) rdopts, options, &constanttable);
>
> where the constant table contains en
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Could you deliver "bool validate" to the validate_string_relopt callback?
In this specification, invoked callback cannot know whether it should
really raise an error for invalid reloption, or not.
Hmm, would it be better to not call the validation cal
KaiGai Kohei wrote:
> Could you deliver "bool validate" to the validate_string_relopt callback?
> In this specification, invoked callback cannot know whether it should
> really raise an error for invalid reloption, or not.
Hmm, would it be better to not call the validation callback at all if
vali
Alvaro Herrera wrote:
> Agreed, it seems better. The attached patch adds that, a macro you
> originally requested and another one, and it also fixes an off-by-one
> bug I discovered while testing all of this. I also attach the testing
> patch I play with to check that this all works nicely.
| **
Alvaro Herrera writes:
> Tom Lane wrote:
>> What you seem to be supposing is that the only possible use pattern
>> for these macros is a for-loop containing nothing but calls to one
>> or another of the macros.
> You're right. I initially wrote these macros to reduce the amount of
> code in heap
Tom Lane wrote:
> Alvaro Herrera writes:
> > Oh, the patch also removes a bunch of "continue" statements that, as far
> > as I can tell, no longer work after the macros were wrapped in
> > do { ... } while (0) :-( I don't see any nice way to put the facility
> > back.
>
> Hmm ... I guess you cou
Alvaro Herrera writes:
> Oh, the patch also removes a bunch of "continue" statements that, as far
> as I can tell, no longer work after the macros were wrapped in
> do { ... } while (0) :-( I don't see any nice way to put the facility
> back.
Hmm ... I guess you could make the wrapping be "if (.
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
>>> 3. Why the "StdRdOptions lopts;" is necessary?
>>
>> It is like this because the autovacuum patch adds a few more options and
>> I want to have the chance to not allocate the part belonging to
>> autovacuum when none of the options are present.
>
> W
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Alvaro, could you check the patched code on reloptions.h, reloptions.c
and rel.h? It is a working example of string reloptions, and I could
found a few strange codes.
I'm intending to revisit the string code ... I was thinking yesterday
night that I s
KaiGai Kohei wrote:
> Alvaro, could you check the patched code on reloptions.h, reloptions.c
> and rel.h? It is a working example of string reloptions, and I could
> found a few strange codes.
I'm intending to revisit the string code ... I was thinking yesterday
night that I shouldn't have commit
I updated patch set of SE-PostgreSQL and related stuff (r1389).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1389.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1389.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy
12 matches
Mail list logo
