| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
two additional files win32.mak and libpgtcl.def.
This patch allows to compile libpgtcl.dll on Windows
with tcl > 8.0. I've tested it on WinNT (VC6.0), SUSE Linux (7.0)
and Solaris 2.6 with tcl 8.3.3.
Mikhail Terekhov
|
|
|
|
|
|
|
|
|
|
|
|
| |
really played it totally safe in my last suggestion, the system table might
pick up the msg but not the netmsg.dll, so better try both.
I also added a hex printout of the "errno" appended to all messages, that's
nicer.
If anyone hate my coding style, or that i'm using goto constructs, just tell
me, and i'll rework it into a nested if () thing.
Magnus Naeslund(f)
|
|
|
|
| |
Update Italian jdbc error messages.
|
| |
|
|
|
|
|
|
|
|
| |
system. Some systems did not understand the 'l' section, and in general
it wasn't entirely appropriate.
On SCO OpenServer, the man pages won't be installed at all until someone
figures out their man system.
|
|
|
|
|
|
|
|
|
|
| |
Client headers are no longer in a subdirectory, since they have been made
namespace-clean.
Internal libpq headers are in a private subdirectory.
Server headers are in a private subdirectory. pg_config has a new option
to point there.
|
| |
|
|
|
|
| |
is a macro.
|
| |
|
| |
|
|
|
|
|
|
| |
platforms and without relinking.
Also support VPATH builds and DESTDIR installs. One hopes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
longer compiles, due to objects being referenced in this patch that do
not exist in JDK1.1.
Barry Lind
---------------------------------------------------------------------------
The JDBC driver requires
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
>>>>
>>>> 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
wrong directory.
|
| |
|
|
|
|
| |
documented wrong.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix '\\' handling for bytea type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Shouldn't
>
> throw new PSQLException("metadata unavailable");
>
> in getTypeInfo() be something like:
>
> throw new PSQLException("postgresql.meta.unavailable");
>
> to allow translation of the error message in the
> errors*.properties files?
You're right. Attached is an updated patch that also includes a message
in error.properties. I've attempted a French message in
errors_fr.properties but beware that I haven't written French in quite a
few years. Don't know Italian, German, or Dutch so I can't do those.
Liam Stewart
|
| |
|
|
|
|
| |
- Include some patches by Christof Petig <christof.petig@wtal.de>.
|
|
|
|
|
|
|
|
| |
SQLxxxx() to PGAPI_xxxx().
2) Handle an escaped date/time format as a parameter.
3) Improve the tuple allocation a little.
4) The preparation of ODBC 3.0 a little.
5) Updatable cursors(may be deprecated before long).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
reflect a mail thread that discussed our conformance (or lack thereof)
to the SQL92 spec.
Barry Lind
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attempt at a patch to 7.1.2 to support Array.
[I think I've solved the mangled patch problem. Hotmail seems to
try to format the text file, so gzipping it should solve this
problem.]
In this patch I've incorporated Barry's feedback. Specifically:
1) OIDs are no longer hard-coded into Array.java. In order to
support this change I added a getOID(String) method to Field.java
which receives a PostgreSQL field type and returns a value from
java.sql.Types. I couldn't get away from using OIDs altogether
because the JDBC spec for Array specifies that some methods return
a ResultSet. This requires I construct Field objects,
which means I need OIDs. At least this approach doesn't hard
code these values. A Hashtable cache has been added to Field
so that an SQL lookup isn't necessary (following the model already
in Field.java).
2) Rewired the base formatting code in ResultSet.java to use 'to'
methods, which are then exposed as static methods in ResultSet.
These methods are used in Array to format the data without
duplications in the code.
3) Artifact call to first() in ResultSet.getArray() removed.
Greg Zoller
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
includes two changes in the JDBC driver:
1) When connected to a backend >= 7.2: use obj_description() and
col_description() instead of direct access to pg_description.
2) In DatabaseMetaData.getTables()/getColumns()/getProcedures():
when there is no comment on the object, return null in the
REMARKS column of the ResultSet, instead of the default string
"no remarks".
Change 2 first appeared as a side-effect of change 1, but it is
actually more compliant with the JDBC spec: "String object
containing an explanatory comment on the table/column/procedure,
which may be null". The default string "no remarks" was strictly
speaking incorrect, as it could not be distinguished from a real
user comment "no remarks". So I removed the default string
completely.
Change 2 might break existing code that doesn't follow the JDBC
spec and isn't prepared to handle a null in the REMARKS column
of getTables()/getColumns()/getProcedures.
Patch tested with jdbc2 against both a 7.1 and a CVS tip
backend. I did not have a jdbc1 environment to build and test
with, but since the touched code is identical in jdbc1 and jdbc2
I don't foresee any problems.
Regards,
Ren? Pijlman
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
has an alias SERIAL4 and a sister SERIAL8. SERIAL8 is just the same
except the created column is type int8 not int4.
initdb forced. Note this also breaks any chance of pg_upgrade from 7.1,
unless we hack up pg_upgrade to drop and recreate sequences. (Which is
not out of the question, but I don't wanna do it.)
|
|
|
|
|
|
|
| |
the first result in the DB-API compliant wrapper. It turned out that the bug
was way down in the C code.
Gerhard Häring
|
| |
|
| |
|
|
|
|
|
|
|
| |
Allow pg_shadow to be MD5 encrypted.
Add ENCRYPTED/UNENCRYPTED option to CREATE/ALTER user.
Add password_encryption postgresql.conf option.
Update wire protocol version to 2.1.
|
| |
|
|
|
|
| |
our own code ...
|
|
|
|
|
|
|
|
|
|
|
|
| |
default, but OIDS are removed from many system catalogs that don't need them.
Some interesting side effects: TOAST pointers are 20 bytes not 32 now;
pg_description has a three-column key instead of one.
Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey
has some usefulness; pg_dump dumps comments on indexes, rules, and
triggers in a valid order.
initdb forced.
|
|
|
|
|
|
|
|
|
|
|
| |
* Merges identical code from org.postgresql.jdbc[1|2].Statement into
org.postgresql.Statement.
* Moves escapeSQL() method from Connection to Statement (the only place
it's used)
* Minor cleanup of the new isolation level stuff.
* Minor cleanup of version string handling.
Anders Bengtsson
|