- 10 9月, 2001 26 次提交
-
-
由 Bruce Momjian 提交于
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>
-
由 Bruce Momjian 提交于
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
-
由 Bruce Momjian 提交于
>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>
-
由 Bruce Momjian 提交于
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
-
由 Bruce Momjian 提交于
Given the following table: test=# \d f Table "f" Column | Type | Modifiers --------+---------+----------- i | integer | test | text | If I do the following: test=# insert into f values(1,'test'); INSERT 139549 1 test=# select i::int8,test from f; ?column? | test ----------+------ 1 | test (1 row) It doesn't make much sense that the first column should be called '?column?'. The patch results in the output appearing like this: test=# select i::int8,test from f; i | test ---+------ 1 | test (1 row) ---------- Gavin Sherry
-
由 Bruce Momjian 提交于
> > "parse error at [the] end of line" > > Attached patch also fixes it. I noticed this while editing the po file. > If I'm wrong, please ignore the command.c.patch. I will revert my translation > as well then. > > -- > Serguei A. Mokhov
-
由 Bruce Momjian 提交于
PostgreSQL to support unicode-conversion, but retains binary compatibility among Tcl versions. However, it neither checks at compile time not at runtime, if support for unicode-conversion does really exist and it doesn't prevent the user from changing the client encoding after initialization. I think there should be warnings about this somewhere in the documentation. Reinhard Max
-
由 Hiroshi Inoue 提交于
-
由 Hiroshi Inoue 提交于
2) Fix a bug with NUMERIC scale in case of Parse statement option. 3) Remove a no longer needed loop in CC_send_query(). Hiroshi Inoue
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
pg_ctl instead.
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
- 09 9月, 2001 5 次提交
-
-
由 Tatsuo Ishii 提交于
-
由 Tatsuo Ishii 提交于
-
由 Peter Eisentraut 提交于
-
由 Hiroshi Inoue 提交于
Add a new DSN option for PREPARE hadling. Hiroshi Inoue
-
由 Hiroshi Inoue 提交于
-
- 08 9月, 2001 9 次提交
-
-
由 Peter Eisentraut 提交于
Assign the fixed user id 1 to the user created by initdb. A stand-alone backend will always set the user id to 1. (Consequently, the name of that user is no longer important.) In stand-alone mode, the user id 1 will have implicit superuser status, to allow repairs even if there are no users defined. Print a warning message when starting in stand-alone mode when no users are defined. Disallow dropping the current user and session user. Granting/revoking superuser status also grants/revokes usecatupd. (Previously, it would never grant it back. This could lead to "deadlocks".) CREATE USER and CREATE GROUP will start allocating user ids at 100 (unless explicitly specified), to prevent accidental creation of a superuser (plus some room for future extensions).
-
由 Bruce Momjian 提交于
> > ClientEncoding to SQL_ASCII (like default DatabaseEncoding). Bruce, can > > you change it? It's one line change. Again thanks. Forget it! A default client encoding must be set by actual database encoding... Please apply the small attached patch that solve it better. Karel Zak
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Hiroshi Inoue 提交于
Rename psqlodbc.def -> psqlodbc_win32.def. Improve internal *declare cursor* handling a little. Hiroshi Inoue
-
由 Tom Lane 提交于
We will no longer try to send elog messages to the client before we have initialized backend libpq (oops); however, reporting bogus commandline switches via elog does work now (not irrelevant, because of PGOPTIONS). Fix problem with inappropriate sending of checkpoint-process messages to stderr.
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
don't have more bugs like the quote-quote-quote-quote one. Propagate fix into ecpg lexer, too.
-
由 Bruce Momjian 提交于
suite. This reduces the number of failures from 9 to 7. Both ConnectionTest and JBuilderTest did not create their own tables, which caused these test cases to fail with "relation ... does not exist". It appears these test cases relied on tables created by the example code elsewhere in the source tree. I've added the necessary "create table" and "drop table" statements to the test cases, using the column definitions from the example code. While working on that I modified the helper method createTable in JDBC2Tests.java to take a table parameter, rather than using table names passed via the properties in build.xml. I'm not sure what that was good for, and in fact, except for the default table name "jdbctest", this functionality wasn't used at all. Ren? Pijlman
-