> situation is already tracked in File routines, but a little bit
> incorrectly.

> After small survey in Linux kernel code, I am not sure about
> it.  New patch set pos to unknown in the case of read/write
> fails. And do lseek again.

> Here is the full patch for this. This patch reduce amount of
> lseek call ten ti mes for update statement and twenty times for
> select statement. I tested joined up date and count(*) select
> for table with rows > 170000 and 10 indices.  I think this is
> worse of trying. Before lseek calls account for more than 5% o
> f time.  Now they are 0.89 and 0.15 respectevly.
>
> Due to only one file modification patch should be applied in
> src/backedn/stora ge/file/ dir.

-- Sincerely Yours,
Denis Perchine

have'nt r un autoconf to create a new configure, I guess that's done by
the smapshot process, I had to remove a line from interface/odbc/
GNUMakefile to get it to build, it was a autoconf variable that looks to
not be used anymore, I am assuming that this is  ok.

Nick Gorham
Easysoft Ltd

the
tcl-spec in the Makefile.
The patch in the attachemant does this in the src/interfaces/libpgtcl
too

Thank you
 Rudolf Weber

functions that take pass-by-value datatypes.  Should be ready for
port testing ...

compatiblity with old rules.

prepared for dirtribution (it needs a little changes). I can change and work
on this, but I need motivation :-)

And Peter, I know and I agree that standard PG tree is not good space for
all interfaces and for all tools based on PG, but LO is PG feature and we
haven't backup tool for LO.


Karel Zak

>> Makefile where the make bombs if "." is not in the builder's path?
>> The last I checked, it wasn't applied and the fix is very easy
>> (explicitly use "./" to call the script).

 SL Baur

quote-stripping, and acl-checking tasks for these functions from the
parser, and do them at function execution time instead.  This fixes
the failure of pg_dump to produce correct output for nextval(Foo)
used in a rule, and also eliminates the restriction that the argument
of these functions must be a parse-time constant.

Interfaced a lot of the custom tests to the config.cache, in the process
made them separate macros and grouped them out into files. Made naming
adjustments.

Removed a couple of useless/unused configure tests.

Disabled C++ by default. C++ is no more special than Perl, Python, and Tcl.
And it breaks equally often. :(

that now functions as a wrapper around the MakeMaker stuff. It might
even behave sensically when we have separate build dirs. Same for plperl,
which of course still doesn't work very well. Made sure that plperl
respects the choice of --libdir.

Added --with-python to automatically build and install the Python interface.
Works similarly to the Perl5 stuff.

Moved the burden of the distclean targets lower down into the source tree.
Eventually, each make file should have its own.

Added automatic remaking of makefiles and configure. Currently only for the
top-level because of a bug(?) in Autoconf. Use GNU `missing' to work around
missing autoconf and aclocal. Start factoring out macros into their own
config/*.m4 files to increase readability and organization.

really worked.  Until now.

fflush(stderr)'s for good luck.

here bother to run autoconf, or pay attention when it complains?
To say nothing of actually committing the configure that goes with the
configure.in.
-- Tom the janitor.

absolute.  It also makes it more compliant with the interface
specification in Sun's documentation;

1. absolute(0) should throw an exception.
2. absolute(>num-records) should set the current row to after the last
record in addition to returning false.
3. absolute(<num-records) should set the current row to before the first
record in addition to returning false.

These operations in the existing code just return false and don't change
current_row.

These changes required a minor change to relative(int) since it calls
absolute(int)

The attached patch is against the cvs repository tree as of this morning.

Also, who is in charge of maintaining the jdbc driver?  I'm working on
getArray for the jdbc2 driver, but it's going to require three more
classes to be added to the driver, and thus three more source files
in the repository.  Is there someone I can contact directly to ask about
this?

Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer