the versioning works. There's also a new utils directory used by Makefile

encodings

currently ISO8859-[1-5] and EUC_JP are supported.
support for other encodings will be coming soon.

(failed to say that it conflicts with AccessShareLock).

(will be used in a future pg_dump).

anyway, the rest being due to them not being kept in sync.  Add configure
test for lorder and use it (on Solaris) when found.

it previously.  The patch included is against fairly current sources, but
it may apply cleanly against 7.0.2 as well.

On Fri, 6 Oct 2000, Vilson farias wrote:

> I found a irregular behavior with constraints.
>
> I can only set a referencial integrity between these tables when there are
> no data, even if there are no change to referential integrity violation.

- Support for 'isstrict' procedure attribute.
- Disable --blobs and --table
(replaced prior to attempting to fix sequence dump problems)

process, the need for changes to the FAQ_SCO document was uncovered.  The
attach patch file implements thost changes.

Billy G. Allie

installing into a shared location.  Also Makefile.global organizational
cleanup.

couldn't produce a full patch using cvs diff -c this time since I have
created new files and anonymous cvs usage doesn't allow you to
adds. I'm supplying the modified src/interfaces/jdbc as a tarball at :
http://www.candleweb.no/~gunnar/projects/pgsql/postgres-jdbc-2000-10-05.tgz

The new files that should be added are :

? org/postgresql/PGStatement.java
? org/postgresql/ObjectPool.java
? org/postgresql/ObjectPoolFactory.java

There is now a global static pool of free byte arrays and used byte arrays
connected to a statement object. This is the role of the new PGStatement
class. Access to the global free array is synchronized, while we rely on
the PG_Stream synchronization for the used array.

My measurements show that the perfomance boost on this code is not quite as
big as my last shot, but it is still an improvement. Maybe some of the
difference is due to the new synchronization on the global array. I think I
will look into choosing between on a connection level and global level.

I have also started experimented with improving the performance of the
various conversions. The problem here is ofcourse related handle the
various encodings. One thing I found to speed up ResultSet.getInt() a lot
was to do custom conversion on the byte array into int instead of going
through the getString() to do the conversion. But I'm unsure if this is
portable, can we assume that a digit never can be represented by more than
one byte ? It works fine in my iso-latin-8859-1 environment, but what about
other environments ? Maybe we could provide different ResultSet
implementations depending on the encoding used or delegate some methods of
the result set to an "converter class".

Check the org/postgresql/jdbc2/FastResultSet.java in the tarball above to
see the modified getInt() method.

Regards,

        Gunnar