From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Sigh ... |
Date: | 2008-05-02 23:23:34 |
Message-ID: | 26929.1209770614@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> This doesn't look quite right; unless the arithmetic is being done in
>> floating point? I had it like this in configure.in:
>>
>> RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
> blocksize is one of (1,2,4,8,16,32) so it should always be a factor of
> 1024 unless my arithmetic is awry. I did it that way because I dislike
> expressions with unbracketed mixed operations - they make me think too
> much.
Well, if you dislike the original on style grounds, you should change it
to match. Doing the same thing in two different ways in two places
isn't good.
>> Also it looks like you missed adding segsize to the config.pl comments.
> That's deliberate - we are currently only allowing a value of 1 here, so
> I don't see any point in putting it in the sample config file, even as a
> comment. When we enable other seg sizes we can add it to the sample file.
Ah, OK.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-03 00:11:36 | pgsql: Support RETURN QUERY EXECUTE in plpgsql. |
Previous Message | Andrew Dunstan | 2008-05-02 23:05:05 | Re: [COMMITTERS] pgsql: Sigh ... |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-05-03 00:26:29 | Re: [COMMITTERS] pgsql: Sigh ... |
Previous Message | Tom Lane | 2008-05-02 23:19:00 | Re: ecpg localization |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-05-02 23:24:21 | Re: Exposing keywords to clients |
Previous Message | Tom Lane | 2008-05-02 23:05:52 | Re: plpgsql CASE statement - last version |