2012-04-08 19:38 keltezéssel, Michael Meskes írta:
On Sun, Apr 08, 2012 at 06:35:33PM +0200, Boszormenyi Zoltan wrote:
Do you want me to change this or will you do it? I am on holiday
and will be back to work on wednesday.
I don't think waiting till later this week is a real problem.
OK.
The possibility to test different readahead window sizes
without modifying the source and recompiling was useful.
Sure, but you can still do that when not defining a fixed number in the
statement.
OK.
The -R option simply provides a default without ornamenting
the DECLARE statement.
Could you please incorporate these changes, too, when you're back from vacation?
Sure.
So, it's established that a specified READAHEAD N should not
be overridden. Even an explicit READAHEAD 1.
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?
I cannot find a test that tests the environment variable giving the fetch size.
Could you please point me to that?
I didn't write such a test. The reason is that while variables are
exported by make from the Makefile to the binaries run by make
e.g. CFLAGS et.al. for $(CC), "make check" simply runs pg_regress
once which uses its own configuration file that doesn't have a
way to set or unset an environment variable. This could be a useful
extension to pg_regress though.
How about calling setenv() from the test program itself?
Sure, I didn't think about it. It should be done before the
first EXEC SQL OPEN cursor.
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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
