>>>>
>>>> permission java.net.SocketPermission "host:port", "connect";
>>>>
>>>>in the policy file of the application using the JDBC driver
>>>>in the postgresql.jar file.  Since the Socket() call in the
>>>>driver is not protected by AccessController.doPrivileged() this
>>>>permission must also be granted to the entire application.
>>>>
>>>>The attached diff fixes it so that the connect permission can be
>>>>restricted just the the postgresql.jar codeBase if desired.

David Daney

OU8.

Larry Rosenman

org.postgresql.util.Serialize and org.postgresql.jdbc2.PreparedStatement
that  fixes the ability to "serialize" a simple java class into a
postgres table.

The current cvs seems completely broken in this support, so the patch
puts it  into working condition, granted that there are many limitations
with  serializing java classes into Postgres.

The code to do serialize appears to have been in the driver since
Postgres  6.4, according to some comments in the source.  My code is not
adding any  totally new ability to the driver, rather just fixing what
is there so that  it actually is usable.  I do not think that it should
affect any existing  functions of the driver that people regularly
depend on.

The code is activated if you use jdbc2.PreparedStatement and try to
setObject  some java class type that is unrecognized, like not String or
not some other  primitive type.  This will cause a sequence of function
calls that results in  an instance of Serialize being instantiated for
the class type passed.  The  Serialize constructor will query pg_class
to see if it can find an existing  table that matches the name of the
java class. If found, it will continue and  try to use the table to
store the object, otherwise an SQL exception is  thrown and no harm is
done.  Serialize.create() has to be used to setup the  table for a java
class before anything can really happen with this code other  than an
SQLException (unless by some freak chance a table exists that it  thinks
it can use).

I saw a difference in Serialize.java between 7.1.3 and 7.2devel that I
didn't  notice before, so I had to redo my changes from the 7.2devel
version (why I  had to resend this patch now).  I was missing the
fixString stuff, which is  nice and is imporant to ensure the inserts
will not fail due to embedded  single quote or unescaped backslashes. I
changed that fixString function in  Serialize just a little since there
is no need to muddle with escaping  newlines: only escaping single quote
and literal backslashes is needed.  Postgres appears to insert newlines
within strings without trouble.

buffer manager with 'pg_clog', a specialized access method modeled
on pg_xlog.  This simplifies startup (don't need to play games to
open pg_log; among other things, OverrideTransactionSystem goes away),
should improve performance a little, and opens the door to recycling
commit log space by removing no-longer-needed segments of the commit
log.  Actual recycling is not there yet, but I felt I should commit
this part separately since it'd still be useful if we chose not to
do transaction ID wraparound.

wrong directory.

backend gets on -o option like the regular backend.

documented wrong.

bigserial and alias for serial8 for consistency with bigint/int8.

on Windows. I'm not sure it is the best way to fix them
(see patch below.)

Mikhail Terekhov with mods by Tom Lane

  This patch moves the logic that looks up TypeOid, PGTypeName, and
SQLTypeName from Field to Connection.  It is moved to connection since
it needs to differ from the jdbc1 to jdbc2 versions and Connection
already has different subclasses for the two driver versions.  It also
made sense to move the logic to Connection as some of the logic was
already there anyway.

Barry Lind

places that were including the wrong files.

(TransactionIdPrecedes, TransactionIdFollows, etc).  First step on the
way to transaction ID wrap solution ...

make it use Makefile.shlib, etc.

Unixen spell it 'Inf').  Not worth adding multiple expected files and
a resultmap just for this.

interval arithmetic.  From Teodor Sigaev.

the declared result type, rather than requiring exact type match as
before.  Per pghackers discusssion of 14-Aug.

\connect, to avoid possible password prompts and such, at the drawback of
having to have superuser access.

From Oleg Bartunov and Teodor Sigaev.

for haskeytype).  Update GiST contrib modules too.  Add linear-time split
algorithm for R-tree GiST opclass.
From Oleg Bartunov and Teodor Sigaev.

following email.

 > > The problem:  When I call getBigDecimal() on a ResultSet, it
 > > sometimes throws an exception:
 > >
 > >   Bad BigDecimal 174.50
 > >     at org.postgresql.jdbc2.ResultSet.getBigDecimal(ResultSet.java:373)
 > >     at org.postgresql.jdbc2.ResultSet.getBigDecimal(ResultSet.java:984)
 > >     ...blah blah blah...
 > >   org.postgresql.util.PSQLException: Bad BigDecimal 174.50

Barry Lind

so it may be a transit problem.  Also removed the 'txt' suffix
in case that was confusing some transport layer trying to be
too inteligent for our own good.

This may have been because the Array.java class from the
previous patch didn't seem to have made it into the snapshot
build for some reason.  This patch should at least fix that issue.

Greg Zoller

discussion in pgsql-general.

> It seems that win9x doesn't have the "netmsg.dll" so it defaults to "normal"
> FormatMessage.
> I wonder if one could load wsock32.dll or winsock.dll on those systems
> instead of netmsg.dll.
>
> Mikhail, could you please test this code on your nt4 system?
> Could someone else test this code on a win98/95 system?
>
> It works on win2k over here.

It works on win2k here too but not on win98/95 or winNT.
Anyway, attached is the patch which uses Magnus's my_sock_strerror
function (renamed to winsock_strerror). The only difference is that
I put the code to load and unload netmsg.dll in the libpqdll.c
(is this OK Magnus?).

Mikhail Terekhov

pgsql-hackers.  pg_opclass now has a row for each opclass supported by each
index AM, not a row for each opclass name.  This allows pg_opclass to show
directly whether an AM supports an opclass, and furthermore makes it possible
to store additional information about an opclass that might be AM-dependent.
pg_opclass and pg_amop now store "lossy" and "haskeytype" information that we
previously expected the user to remember to provide in CREATE INDEX commands.
Lossiness is no longer an index-level property, but is associated with the
use of a particular operator in a particular index opclass.

Along the way, IndexSupportInitialize now uses the syscaches to retrieve
pg_amop and pg_amproc entries.  I find this reduces backend launch time by
about ten percent, at the cost of a couple more special cases in catcache.c's
IndexScanOK.

Initial work by Oleg Bartunov and Teodor Sigaev, further hacking by Tom Lane.

initdb forced.