environment strings need to be moved around, do so when called from
initial startup (main.c), not in init_ps_status. This eliminates the
former risk of invalidating saved environment-string pointers, since
no code has yet had a chance to grab any such pointers when main.c
is running.
in .:/home/postgres/testversion/bin:/opt/perl5.6.1/bin:/home/postgres/bin:/usr/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/usr/contrib/bin:/opt/nettladm/bin:/opt/pd/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/upgrade/bin:/opt/CC/bin:/opt/langtools/bin:/opt/graphics/phigs/bin:/opt/java/bin:/bin:/opt/imake/bin:/opt/hparray/bin:/opt/aCC/bin:/opt/lrom/bin:/usr/local/nmh/bin:. (I suppose the only common case for this is '.').
per suggestion from Peter. Simplify several APIs by transmitting the
original argv location directly from main.c to ps_status.c, instead of
passing it down through several levels of subroutines.
Mask both typmod subfields for INTERVAL to avoid setting the high bit,
per dire warning from Tom Lane.
Clear tmask for DTK_ISO_TIME case to avoid time zone troubles.
Symptom reported by Tom Lane.
Clean up checking for valid time zone info in output routine.
This should now work for both SQL99 and Unix-style time zones.
Put in explicit check for INTERVAL() typmod rounding to avoid accumulating
cruft in the lower bits. Not sure that this helps, but we'll need to do
something. The symptom is visible with a query like
select interval(2) '10000 days 01:02:03.040506';
Regression tests are patched to repair the Tom Lane symptom, and all pass.
subprocesses; perhaps this will fix portability problem just noted by
Lockhart. Also, move test for bad permissions of DataDir to a more
logical place.
bootstrap) check for a valid PG_VERSION file before looking at anything
else in the data directory. This fixes confusing error report when
trying to start current sources in a pre-7.1 data directory.
Per trouble report from Rich Shepard 10/18/01.
just after receipt of the startup packet. Now, postmaster children
that are waiting for client authentication response will show as
'postgres: user database host authentication'. Also, do an
init_ps_display for startup/shutdown/checkpoint subprocesses,
so that they are readily identifiable as well. Fix an obscure race
condition that could lead to Assert failure in the postmaster ---
attempting to start a checkpoint process before any connections have
been received led to calling PostmasterRandom before setting random_seed.
authentication failed' and a 'send() failed: Broken pipe' message
on every connection from psql in password auth mode. Problem is
that psql doesn't ask user for a password until it sees a password
challenge failure, and libpq just closes the connection unceremoniously
if it's challenged for a password when it hasn't got one to send.
Accordingly, EOF from the client after asking for a password is
normal behavior and should not result in postmaster log entries.
the entered password would get echoed on some platforms, eg HPUX.
We have enough copies of this code that I'm thinking it ought to be
moved into libpq, but that's a task for another day.
Modified the parser and the SET handlers to use full Node structures
rather than simply a character string argument.
Implement INTERVAL() YEAR TO MONTH (etc) syntax per SQL99.
Does not yet accept the goofy string format that goes along with, but
this should be fairly straight forward to fix now as a bug or later
as a feature.
Implement precision for the INTERVAL() type.
Use the typmod mechanism for both of INTERVAL features.
Fix the INTERVAL syntax in the parser:
opt_interval was in the wrong place.
INTERVAL is now a reserved word, otherwise we get reduce/reduce errors.
Implement an explicit date_part() function for TIMETZ.
Should fix coersion problem with INTERVAL reported by Peter E.
Fix up some error messages for date/time types.
Use all caps for type names within message.
Fix recently introduced side-effect bug disabling 'epoch' as a recognized
field for date_part() etc. Reported by Peter E. (??)
Bump catalog version number.
Rename "microseconds" current transaction time field
from ...Msec to ...Usec. Duh!
date/time regression tests updated for reference platform, but a few
changes will be necessary for others.
clause being added to a particular restriction-clause list is redundant
with those already in the list. This avoids useless work at runtime,
and (perhaps more importantly) keeps the selectivity estimation routines
from generating too-small estimates of numbers of output rows.
Also some minor improvements in OPTIMIZER_DEBUG displays.
view when using the aggregate function count() and function nextval
that returns an int8 value, but in python is represented like string:
>> db.query("select nextval('my_seq')").getresult()
[('2',)]
>> db.query("select count(*) from films").dictresult()
[{'count': '120'}]
Ricardo Caesar Lenzi
> ! $$ = cat_str(8, make_str("grant"), $2, make_str("on"), $4, $5,
> make_str("to"), $7, $8);
> ISTM your patch loses the opt_with_grant clause. (Of course the
> backend doesn't currently accept that clause anyway, but that's no
> reason for ecpg to drop it.)
My patch doesn't loose the option, it's never been passed on anyway:
opt_with_grant: WITH GRANT OPTION
{
mmerror(ET_ERROR, "WITH GRANT OPTION is not supported. Only relation owners can
set privileges");
}
| /*EMPTY*/
;
The existing code in ecpg/preproc/preproc.y to handle the WITH option
simply throws an error and aborts the processing... The patch below
prevents the segfault and also passes on the WITH option to the
backend, probably a better fix.
Lee Kindness
> - corrects a bit the UTF-8 code from Tatsuo to allow Unicode 3.1
> characters (characters with values >= 0x10000, which are encoded on
> four bytes).
Also, update mb/expected/unicode.out. This is necessary since the
patches affetc the result of queries using UTF-8.
---------------------------------------------------------------
Hi,
I should have sent the patch earlier, but got delayed by other stuff.
Anyway, here is the patch:
- most of the functionality is only activated when MULTIBYTE is
defined,
- check valid UTF-8 characters, client-side only yet, and only on
output, you still can send invalid UTF-8 to the server (so, it's
only partly compliant to Unicode 3.1, but that's better than
nothing).
- formats with the correct number of columns (that's why I made it in
the first place after all), but only for UNICODE. However, the code
allows to plug-in routines for other encodings, as Tatsuo did for
the other multibyte functions.
- corrects a bit the UTF-8 code from Tatsuo to allow Unicode 3.1
characters (characters with values >= 0x10000, which are encoded on
four bytes).
- doesn't depend on the locale capabilities of the glibc (useful for
remote telnet).
I would like somebody to check it closely, as it is my first patch to
pgsql. Also, I created dummy .orig files, so that the two files I
created are included, I hope that's the right way.
Now, a lot of functionality is NOT included here, but I will keep that
for 7.3 :) That includes all string checking on the server side (which
will have to be a bit more optimised ;) ), and the input checking on
the client side for UTF-8, though that should not be difficult. It's
just to send the strings through mbvalidate() before sending them to
the server. Strong checking on UTF-8 strings is mandatory to be
compliant with Unicode 3.1+ .
Do I have time to look for a patch to include iso-8859-15 for 7.2 ?
The euro is coming 1. january 2002 (before 7.3 !) and over 280
millions people in Europe will need the euro sign and only iso-8859-15
and iso-8859-16 have it (and unfortunately, I don't think all Unices
will switch to Unicode in the meantime)....
err... yes, I know that this is not every single person in Europe that
uses PostgreSql, so it's not exactly 280m, but it's just a matter of
time ! ;)
I'll come back (on pgsql-hackers) later to ask a few questions
regarding the full unicode support (normalisation, collation,
regexes,...) on the server side :)
Here is the patch !
Patrice.
--
Patrice HÉDÉ ------------------------------- patrice à islande org -----
-- Isn't it weird how scientists can imagine all the matter of the
universe exploding out of a dot smaller than the head of a pin, but they
can't come up with a more evocative name for it than "The Big Bang" ?
-- What would _you_ call the creation of the universe ?
-- "The HORRENDOUS SPACE KABLOOIE !" - Calvin and Hobbes
------------------------------------------ http://www.islande.org/ -----
Enabling this feature adds very light overhead of 1 select from pg_class on
first using of pl/tcl in backend if unknown suppport is really unused.
But pl/tcl with this support has very improved functionality.
Patch includes changes to documentation.
side encoding name. This is necessary for client API's such as JDBC
to perform correct encoding conversions. See my email "[HACKERS]
pg_client_encoding" 10 Sep 2001.
transformAlterStmt() use these routines, instead of having lots of
duplicate (not to mention should-have-been-duplicate) code.
Adding a column with a CHECK constraint actually works now,
and the tests to reject unsupported DEFAULT and NOT NULL clauses
actually fire now. ALTER TABLE ADD PRIMARY KEY works, modulo
having to have created the column(s) NOT NULL already.
> As you can see, psql reconnect as any user if the password is same as
> foo. Of course this is due to the careless password setting, but I
> think it's better to prompt ANY TIME the user tries to switch to
> another user. Comments?
Yeah, I agree. Looks like a simple change in dbconnect():
/*
* Use old password if no new one given (if you didn't have an old
* one, fine)
*/
if (!pwparam && oldconn)
pwparam = PQpass(oldconn);
to
/*
* Use old password (if any) if no new one given and we are
* reconnecting as same user
*/
if (!pwparam && oldconn && PQuser(oldconn) && userparam &&
strcmp(PQuser(oldconn), userparam) == 0)
pwparam = PQpass(oldconn);
regards, tom lane
current_timestamp, current_date for ODBC compatibility.
Add more functions to odbc.sql catalog extension, use new CREATE OR
REPLACE FUNCTION.
Document iODBC/unixODBC build options.
That patch broke the ability to read data from binary cursors.
--Barry Lind
Modified Files:
pgsql/src/interfaces/jdbc/org/postgresql/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/UpdateableResultSet.java
NOTICE added about error location (same method already used by plpgsql
executor). Add checking of pg_proc row xmin/cmin to ensure that
plpgsql functions will be recompiled after they've been modified by
CREATE OR REPLACE FUNCTION.
rather than having its own somewhat half-baked notion of what a type
declaration looks like. This is necessary now to ensure that plpgsql
will think a 'timestamp' variable has the same semantics as 'timestamp'
does in the main SQL grammar; and it should avoid divergences in future.
for nested typecasts. It now produces a column header of 'timestamptz'
for 'SELECT CURRENT_TIMESTAMP', rather than 'text' as it was doing for
awhile there.
lookup info in the relcache for index access method support functions.
This makes a huge difference for dynamically loaded support functions,
and should save a few cycles even for built-in ones. Also tweak dfmgr.c
so that load_external_function is called only once, not twice, when
doing fmgr_info for a dynamically loaded function. All per performance
gripe from Teodor Sigaev, 5-Oct-01.
on words as opposed to lines, which means that all of the
following work in psql:
\d foo \d bar
\d foo; \d bar
\d foo \d bar;;
\d foo; <space>
This one also uses "true and false" and strips semicolons
for the following backslash commands: \C \c \d \e \i \o \s \z
Greg Sabino Mullane
readability. Bizarre '(long *) TRUE' return convention is gone,
in favor of just raising an error internally in dynahash.c when
we detect hashtable corruption. HashTableWalk is gone, in favor
of using hash_seq_search directly, since it had no hope of working
with non-LONGALIGNable datatypes. Simplify some other code that was
made undesirably grotty by promixity to HashTableWalk.
type coercion after failing to find an exact match in pg_proc, but before
considering interpretations that involve a function call with one or
more argument type coercions. This avoids surprises wherein what looks
like a type coercion is interpreted as coercing to some third type and
then to the destination type, as in Dave Blasby's bug report of 3-Oct-01.
See subsequent discussion in pghackers.
which contains stack trace.
One problem, after this patch errors will generate multiline ERROR
messages. Is it acceptable or do I need split it and generate multiple
singleline messages?
Vsevolod Lobko
select 'id' as xxx from table
The issue is:
When the driver gets a data type which does not map into the SQL.Types
it attempts to load the object into a java object. Eventually throwing
an exception indicating that the type "unknown" was not found.
Since the backend defaults "unknown" types to text it was suggested that
the jdbc driver do the same.
This patch does just that.
I have tested it on the above select statement as well as a small
program that serializes, and deserializes a class
Dave Cramer
NLS effort for the 'postgresql' component.
It includes 'ru.po', which should be added
to /src/backend/po/ and a typical patch for
nls.mk with the 'ru' entry added in
the AVAIL_LANGUAGES.
I'll submit a patch with more translations
for pg_dump once CVSweb becomes available.
CVSweb for me right now is the only way
to get to the source code until my system
is completely setup by the end of the week.
--
Serguei A. Mokhov
'aggname (aggtype)'. The old syntax 'aggname aggtype' is still accepted
for backwards compatibility. Fix pg_dump, which was actually broken for
most cases of user-defined aggregates. Clean up error messages associated
with these commands.
-infinity and +infinity. Put TIMESTAMP_NOT_FINITE guard into the routine,
instead of forgetting it at some call sites. Fixes regression test
failures here.
time zones.
SQL99 spec requires a default of zero (round to seconds) which is set
in gram.y as typmod is set in the parse tree. We *could* change to a
default of either 6 (for internal compatibility with previous versions)
or 2 (for external compatibility with previous versions).
Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and
other date/time types. Try to recognize cases where side effects like the
current time zone setting may have an effect on results to decide whether
something is cachable or not.
pg_get_indexdef() function, rather than reaching into the system catalogs
for itself. This eliminates a fair amount of redundant code. Also,
since I just changed pg_get_indexdef() to suppress display of default
index opclasses, this will mean that 7.2 and later dumps will not mention
opclasses unless they are non-default opclasses. Should make life easier
for future index opclass reorganizations.
it to suppress index opclass output for opclasses that are the default
for their datatype; only non-default opclasses are shown explicitly.
This is expected to improve portability of the CREATE INDEX command
across future versions of Postgres --- we've changed index opclasses
too often in the past to think we won't do so again.
Partial support for BEOS (not sure whether second fork of grandchild
process needs these extra calls or not; someone who has BEOS will need
to test it).
> > > > > and --enable-unicode-convertion if it ought to work correctly
> > > > > with Tcl/Tk >= 8.1 (client or server side).
> > > > >
> > > > > - PL/Tcl needs to be changed to use pg_do_encoding_conversion
> > > > > if it runs on a Tcl version >= 8.1 .
> > >
> > > > I'll do pl/tcl part in the next version of patch. Using this approach we
> > > > can eliminate overhead for databases in UNICODE.
> > >
> > > Any progress on this? I'd prefer to get rid of this --enable-pltcl-utf
> > > option before release.
> >
> > Done
> >
> > Next version removes --enable-pltcl-utf switch and enables embedded
> > utf conversion of pgsql if tcl version >=8.1 and --enable-unicode-conversion
portability issues). Caller-visible data structures are now allocated
on MAXALIGN boundaries, allowing safe use of datatypes wider than 'long'.
Rejigger hash_create API so that caller specifies size of key and
total size of entry, not size of key and size of rest of entry.
This simplifies life considerably since each number is just a sizeof(),
and padding issues etc. are taken care of automatically.
from the config file, so that these changes will propagate to backends
started later. Already-started backends continue to ignore changes
in these variables.
upper limit on what we will believe from sysconf(_SC_OPEN_MAX). The
default value is 1000, so that under ordinary conditions it won't
affect the behavior. But on platforms where the kernel promises far
more than it can deliver, this can be used to prevent running out of
file descriptors. See numerous past discussions, eg, pgsql-hackers
around 23-Dec-2000.
rightmost on its tree level, we split 2/3 to the left and 1/3 to the
new right page, rather than the even split we use elsewhere. The idea
is that when faced with a steadily increasing series of inserted keys
(such as sequence or timestamp values), we'll end up with a btree that's
about 2/3ds full not 1/2 full, which is much closer to the desired
steady-state load for a btree. Per suggestion from Ann Harrison of
IBPhoenix.
pointers to data that will be changed by any later call to setlocale.
Must copy what they return to be sure we get the right answer.
Karel Zak, further tweaks by Tom Lane.
existing lock manager and spinlocks: it understands exclusive vs shared
lock but has few other fancy features. Replace most uses of spinlocks
with lightweight locks. All remaining uses of spinlocks have very short
lock hold times (a few dozen instructions), so tweak spinlock backoff
code to work efficiently given this assumption. All per my proposal on
pghackers 26-Sep-01.
two performance improvements. I put an explanation of the
changes at
http://cs1.cs.nyu.edu/been/postgres-rtree.html
The performance improvements are quite significant.
All the changes are in the file src/backend/access/rtree/rtree.c
I was working with the 7.1.3 code.
I'm including the diff output as an attachment.
Kenneth Been
DatabaseMetaData.getColumn(). I proposed a patch that would change the
number of queries to find out all columns in a table from 2 * N + 1 to 1 (N
being the number of columns reported) by using some outer joins. I also
fixed the fact that getColumns() only returned columns that had a default
defined. OTOH, I did not use to change the code required for obtaining a
column's remarks (by using col_description() for 7.2 and requested by Tom
Lane).
Finally, I have found a way to get all the column details in a single query
*and* use col_description() for 7.2 servers. A patch is attached. It
overrules Ren? Pijlman's fix for this that was committed just today, but
still used N + 1 queries (sorry Ren? ;-) )
I also fixed the return values for TABLE_CAT and TABLE_SCHEM from "" to
null, to be more standard compliant (and requested in Ren?'s mail found at
http://fts.postgresql.org/db/mw/msg.html?mid=1034253).
As always, the JDBC1 version has not been tested as I have no JDK 1.1
Jeroen van Vianen
Define a new function, GetCurrentTransactionStartTimeUsec() to get the time
to this precision.
Allow now() and timestamp 'now' to use this higher precision result so
we now have fractional seconds in this "constant".
Add timestamp without time zone type.
Move previous timestamp type to timestamp with time zone.
Accept another ISO variant for date/time values: yyyy-mm-ddThh:mm:ss
(note the "T" separating the day from hours information).
Remove 'current' from date/time types; convert to 'now' in input.
Separate time and timetz regression tests.
Separate timestamp and timestamptz regression test.
check *can* return HEAPTUPLE_INSERT_IN_PROGRESS or HEAPTUPLE_DELETE_IN_PROGRESS,
even though we have ShareLock on the relation. To wit, this can happen
if the tuple was inserted/deleted by our own transaction. Per report from
Justin Clift 9/23.
summary of changes:
. removal of the tablename property from build.xml
. addition of a dropTable method in JDBC2Tests and cleanups of many
methods in the same
. all tests now use non-deprecated assertXYZ methods instead of the
deprecated assert method
. failure in TimestampTest (testSetTimestamp) fixed. The failure is
because testSetTimestamp was inserting a timestamp with hour 7 but
checkTimeTest was expecting a timestamp with hour 8. AFAICS, there are
no issues wrt daylight savings time and timestamps being pushed in and
pulled out (but more explicit tests should be added in the future)
. failure in TimeTest (testGetTime) fixed. Times to be inserted were
interpreted in the localtime zone but checking was done with the
assumption that the insertion was done in GMT.
. formatting changes in a few of the source files (because I found
it convenient to have consistent formatting while working on them). The
formatting is consistent with the new format for java source files in
PostgreSQL.
Liam Stewart
an already installed iODBC or unixODBC driver manager. In particular,
use the include files provided by the driver manager over our own,
and use the odbcinst library of the driver manager rather than gpps.c.
Migrate portability sections common to several files into psqlodbc.h.
a hung client or lost connection can't indefinitely block a postmaster
child (not to mention the possibility of deliberate DoS attacks).
Timeout is controlled by new authentication_timeout GUC variable,
which I set to 60 seconds by default ... does that seem reasonable?
Frank Miles 7-Sep-01. This is really just sticking a finger in the dike.
Frank's case works now, but we still couldn't support a recursive function
returning a set. Really need to restructure querytrees and execution
state so that the querytree is *read only*. We've run into this over and
over and over again ... it has to happen sometime soon.
the JDBC driver.
This method is currently unimplemented and always returns
ResultSetMetaData.columnNullable. This is obviously incorrect
when a column is defined with NOT NULL or PRIMARY KEY. And we
have to think of check constraints, views, functions etc.
The patch simply changes the return value to
ResultSetMetaData.columnNullableUnknown. This is until someone
comes up with a real implementation of course.
On Fri, 14 Sep 2001 17:53:50 +0200, Tomisaw Kity?ski wrote:
>Hello there,
>
>could someone tell me, please, do I have any chance to get
>proper implementation of above method in JDBC (1.1+) soon?
>
>Current "return 1" works fine on most tables, however it seems
>to be a little bit incorrect with some of them ;)
Ren? Pijlman
by escape processing in the SQL statement. I've tested this for a
while now and it appears to work well. Previously string data
with {d was getting corrupt as the {d was being stripped regardless
of whether it was an escape code or not.
I also added checking for time and timestamp escape processing strings
as per 11.3 in the specification. The patch is against the latest
CVS.
Thomas O'Dowd
under libdir, for a cleaner separation in the installation layout
and compatibility with binary packaging standards. Point backend's
default search location there. The contrib modules are also
installed in the said location, giving them the benefit of the
default search path as well. No changes in user interface
nevertheless.
>
> 1. Now outputs '\\' instead of '\134' when using encode(bytea, 'escape')
> Note that I ended up leaving \0 as \000 so that there are no ambiguities
> when decoding something like, for example, \0123.
>
> 2. Fixed bug in byteain which allowed input values which were not valid
> octals (e.g. \789), to be parsed as if they were octals.
>
> Joe
>
Here's rev 2 of the bytea string support patch. Changes:
1. Added missing declaration for MatchBytea function
2. Added PQescapeBytea to fe-exec.c
3. Applies cleanly on cvs tip from this afternoon
I'm hoping that someone can review/approve/apply this before beta starts, so
I guess I'd vote (not that it counts for much) to delay beta a few days :-)
Joe Conway
> null bytes to be literally '\0', the following can happen:
> 1. User inputs string value as "<null byte>##" where ## are digits in the
> range of 0 to 7.
> 2. PQescapeString converts this to "\0##"
> 3. Escaped string is used in a context that causes "\0##" to be evaluated as
> an octal escape sequence.
I agree that this is a problem, though it is not possible to do
anything harmful with it. In addition, it only occurs if there are
any NUL characters in its input, which is very unlikely if you are
using C strings.
The patch below addresses the issue by removing escaping of \0
characters entirely.
> If the goal is to "safely" encode null bytes, and preserve the rest of the
> string as it was entered, I think the null bytes should be escaped as \\000
> (note that if you simply use \000 the same string truncation problem
> occurs).
We can't do that, this would require 4n + 1 bytes of storage for the
result, breaking the interface.
Florian Weimer
driver's test suite. With previous patches applied, this reduces
the number of failures of the test suite from 6 to 4. The patch
fixes the test case itself, rather than the driver.
Details:
1) The driver correctly provided DatabaseMetaData about the sort
order of NULLs. This was confirmed by Peter Eisentraut on
pgsql-hackers. I fixed the test to accept/require the current
behaviour, and made it dependent on the backend version. See
nullsAreSortedAtStart(), nullsAreSortedAtEnd(),
nullsAreSortedHigh() and nullsAreSortedLow().
2) DatabaseMetaData.supportsOrderByUnrelated() correctly
returned true (an ORDER BY clause can contain columns that are
not in the SELECT clause), but the test case required false.
Fixed that.
3) Replaced deprecated assert() of junit.framework.TestCase by
assertEquals(), assertTrue() and assertNotNull(). This is
because assert will be a new keyword in Java 1.4.
4) Replaced assert(message,false) by the more elegant
fail(message).
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
This patch does the following:
- Adds binary datatype support (bytea)
- Changes getXXXStream()/setXXXStream() methods to be spec compliant
- Adds ability to revert to old behavior
Details:
Adds support for the binary type bytea. The ResultSet.getBytes() and
PreparedStatement.setBytes() methods now work against columns of bytea
type. This is a change in behavior from the previous code which assumed
the column type was OID and thus a LargeObject. The new behavior is
more complient with the JDBC spec as BLOB/CLOB are to be used for
LargeObjects and the getBytes()/setBytes() methods are for the databases
binary datatype (which is bytea in postgres).
Changes the behavior of the getBinaryStream(), getAsciiStream(),
getCharacterStream(), getUnicodeStream() and their setXXXStream()
counterparts. These methos now work against either the bytea type
(BinaryStream) or the text types (AsciiStream, CharacterStream,
UnicodeStream). The previous behavior was that these all assumed the
underlying column was of type OID and thus a LargeObject. The
spec/javadoc for these methods indicate that they are for LONGVARCHAR
and LONGVARBINARY datatypes, which are distinct from the BLOB/CLOB
datatypes. Given that the bytea and text types support upto 1G, they
are the LONGVARBINARY and LONGVARCHAR datatypes in postgres.
Added support for turning off the above new functionality. Given that
the changes above are not backwardly compatible (however they are more
spec complient), I added the ability to revert back to the old behavior.
The Connection now takes an optional parameter named 'compatible'. If
the value of '7.1' is passed, the driver reverts to the 7.1 behavior.
If the parameter is not passed or the value '7.2' is passed the behavior
is the new behavior. The mechanism put in place can be used in the
future when/if similar needs arise to change behavior. This is
patterned after how Oracle does this (i.e. Oracle has a 'compatible'
parameter that behaves in a similar manner).
Misc fixes. Cleaned up a few things I encountered along the way.
Note that in testing the patch I needed to ignore whitespace differences
in order to get it to apply cleanly (i.e. patch -l -i byteapatch.diff).
Also this patch introduces a new file
(src/interfaces/jdbc/org/postgresql/util/PGbytea.java).
Barry Lind
>there is still an unpatched reference to pg_description in
>getColumns(), in both jdbc1 and jdbc2.
This was introduced by Jeroen's patch (see
http://fts.postgresql.org/db/mw/msg.html?mid=1032468). Attached
is a patch that returns getColumns() to using "select
obj_description()" instead of direct access to pg_description,
as per the request by Tom.
I've incorporated Jeroen's fix to left outer join with
pg_attrdef instead of inner join, so getColumns() also returns
columns without a default value.
I have, however, not included Jeroen's attempt to combine
multiple queries into one huge multi-join query for better
performance, because:
1) I don't know how to do that using obj_description() instead
of direct access to pg_description
2) I don't think a performance improvement (if any) in this
method is very important
Because of the outer join, getColumns() will only work with a
backend >= 7.1. Since the conditional coding for 7.1/7.2 and
jdbc1/jdbc2 is already giving me headaches I didn't pursue a
pre-7.1 solution.
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
ConnectionTest.testTransactionIsolation() in the JDBC driver's
test suite. This reduces the number of failures of the test
suite from 7 to 6. The patch fixes the test case itself, rather
than the driver.
In addition to the change described in my posting below, I fixed
the part of the test with autocommit enabled. The author of the
test assumed that setting the transaction isolation level would
have no effect, but in fact it does. Perhaps the test case
worked with pre-7.1 behaviour, when the JDBC driver set the
isolation level in every transaction, instead of using "set
session characteristics". Anyway, now it works with a backend
built from current CVS and the behaviour is JDBC compliant.
I also extended the test case by changing the isolation level
before beginning a transaction and verifying it inside the
transaction.
Regards,
Ren? Pijlman