Hi,
2012-04-10 16:55 keltezéssel, Michael Meskes írta:
> On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
>>> Only a non-decorated cursor can be overridden, even if
>>> a different default readahead window size is specified with
>>> e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used,
>>> if ECPGFETCHSZ is present, its value will be used. ECPGopen()
>>> will need an extra bool argument to distinguish this.
>>>
>>> Is this acceptable? Noah, Michael?
>> Sounds perfect.
> Fine by me.
>
> Michael
you commented on "two new options were added and they should
be suboptions to -r". I looked at "man getopt_long" to see what I can do
about the "-R" option and there seems to be a getsubopt() call which is
an extension to getopt_long. My manpage under Fedora 16 says this:
NAME
getsubopt - parse suboption arguments from a string
SYNOPSIS
#include <stdlib.h>
int getsubopt(char **optionp, char * const *tokens, char **valuep);
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
getsubopt():
_XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
|| /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
I wonder whether the manual parsing of "-r" suboptions may be rewritten
using this function or PostgreSQL supports systems without the above
X/Open or POSIX support levels.
Anyway, to make it possible to rewrite using the above call, I modified "-R"
and it's now "-r readahead=number". Documentation is adjusted.
With the above, it would be possible to use a comma separated list of "-r"
suboptions, e.g. "-r prepare,questionmarks,readahead=16" in one option.
Summary of other changes:
- The result set size detection is a suboption of "-r", documentation is adjusted.
- Only undecorated cursors use ECPGFETCHSZ, documentation is adjusted
- "ecpg --help says ...default 0 (disabled)..." fixed.
- Comment in cursor-readahead.pgc is fixed.
- New regression test that exercises ECPGFETCHSZ=8 and a "non-readahead"
cursor. The stderr file shows the "fetch forward 8" executed by the runtime.
- Also added a note to the documentation about a possible performance trap
if a previously written ECPG application uses its own custom readahead via
multi-row FETCH statements.
This patch should be applied over the two patches I last sent.
Best regards,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig& Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/
