composite type capability makes it possible to create a system view
based on a table function in a way that is hopefully palatable to
everyone. The attached patch takes advantage of this, moving
show_all_settings() from contrib/tablefunc into the backend (renamed
all_settings(). It is defined as a builtin returning type RECORD. During
initdb a system view is created to expose the same information presently
available through SHOW ALL. For example:
test=# select * from pg_settings where name like '%debug%';
name | setting
-----------------------+---------
debug_assertions | on
debug_pretty_print | off
debug_print_parse | off
debug_print_plan | off
debug_print_query | off
debug_print_rewritten | off
wal_debug | 0
(7 rows)
Additionally during initdb two rules are created which make it possible
to change settings by updating the system view -- a "virtual table" as
Tom put it. Here's an example:
Joe Conway
This concludes my changes that restructured the code to support JDBC3.
The jdbc unit tests were also resturctured to allow different tests between
jdbc2 and jdbc3, although currently make check (aka ant test) for JDBC3 just
runs the JDBC2 tests. Of special note the largeobject/PGblob and PGclob
classes have been moved under the jdbc2/jdbc3 specific directories as they
now differ by jdbc version. Also note that this checkin removes the
PostgresqlDataSource and files in the xa directory. A recent checkin has
added new datasource support that replaces the functionality provided by these
classes.
Modified Files:
jdbc/build.xml
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSetMetaData.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2Connection.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2DatabaseMetaData.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSetMetaData.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2Statement.java
jdbc/org/postgresql/jdbc2/Array.java
jdbc/org/postgresql/jdbc2/Jdbc2CallableStatement.java
jdbc/org/postgresql/jdbc2/Jdbc2Connection.java
jdbc/org/postgresql/jdbc2/Jdbc2DatabaseMetaData.java
jdbc/org/postgresql/jdbc2/Jdbc2PreparedStatement.java
jdbc/org/postgresql/jdbc2/Jdbc2ResultSet.java
jdbc/org/postgresql/jdbc2/Jdbc2ResultSetMetaData.java
jdbc/org/postgresql/jdbc2/Jdbc2Statement.java
jdbc/org/postgresql/test/jdbc2/BatchExecuteTest.java
jdbc/org/postgresql/test/jdbc2/BlobTest.java
jdbc/org/postgresql/test/jdbc2/CallableStmtTest.java
jdbc/org/postgresql/test/jdbc2/ConnectionTest.java
jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java
jdbc/org/postgresql/test/jdbc2/DateTest.java
jdbc/org/postgresql/test/jdbc2/DriverTest.java
jdbc/org/postgresql/test/jdbc2/JBuilderTest.java
jdbc/org/postgresql/test/jdbc2/MiscTest.java
jdbc/org/postgresql/test/jdbc2/ResultSetTest.java
jdbc/org/postgresql/test/jdbc2/TimeTest.java
jdbc/org/postgresql/test/jdbc2/TimestampTest.java
jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java
Added Files:
jdbc/org/postgresql/jdbc2/AbstractJdbc2Blob.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2Clob.java
jdbc/org/postgresql/jdbc2/Jdbc2Blob.java
jdbc/org/postgresql/jdbc2/Jdbc2Clob.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3Blob.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3Clob.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3DatabaseMetaData.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3ResultSet.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3Statement.java
jdbc/org/postgresql/jdbc3/Jdbc3Blob.java
jdbc/org/postgresql/jdbc3/Jdbc3CallableStatement.java
jdbc/org/postgresql/jdbc3/Jdbc3Clob.java
jdbc/org/postgresql/jdbc3/Jdbc3Connection.java
jdbc/org/postgresql/jdbc3/Jdbc3DatabaseMetaData.java
jdbc/org/postgresql/jdbc3/Jdbc3PreparedStatement.java
jdbc/org/postgresql/jdbc3/Jdbc3ResultSet.java
jdbc/org/postgresql/jdbc3/Jdbc3ResultSetMetaData.java
jdbc/org/postgresql/jdbc3/Jdbc3Statement.java
jdbc/org/postgresql/test/TestUtil.java
jdbc/org/postgresql/test/jdbc2/Jdbc2TestSuite.java
jdbc/org/postgresql/test/jdbc3/Jdbc3TestSuite.java
Removed Files:
jdbc/org/postgresql/PostgresqlDataSource.java
jdbc/org/postgresql/largeobject/PGblob.java
jdbc/org/postgresql/largeobject/PGclob.java
jdbc/org/postgresql/test/JDBC2Tests.java
jdbc/org/postgresql/xa/ClientConnection.java
jdbc/org/postgresql/xa/TwoPhaseConnection.java
jdbc/org/postgresql/xa/TxConnection.java
jdbc/org/postgresql/xa/XAConnectionImpl.java
jdbc/org/postgresql/xa/XADataSourceImpl.java
sys = malloc(strlen(editorName) + strlen(fname) + 10 + 1);
if (!sys)
return false;
sprintf(sys, "exec '%s' '%s'", editorName, fname);
(note the added quotes to provide a little protection against spaces
and such). Then it's perfectly obvious what the calculation is doing.
I don't care about wasting 20-some bytes, but confusing readers of the
code is worth avoiding.
regards, tom lane
(they are not part of a chain). When failing to find a parent tuple in
an update chain, emit a warning and abandon repair_frag, but do not give
an error as before. This should eliminate the infamous 'No one parent tuple
was found' failure, which we now realize is not a can't-happen condition
but a perfectly valid database state. Per recent pghackers discussion.
heap_mark4update; this avoids situations where a deleted tuple might
look like it is chained to something else. Also, cause all the WAL
redo routines to set t_ctid to equal t_self, rather than leaving it
undefined as before. Make heap_xlog_clean set the page's LSN and SUI
correctly. All per past discussions in pghackers, ranging back to
last December.
to make a reasonable attempt at accounting for palloc overhead, not just
the requested size of each memory chunk. Since in many scenarios this
will make for a significant reduction in the amount of space acquired,
partially compensate by doubling the default value of SORT_MEM to 1Mb.
Per discussion in pgsql-general around 9-Jun-2002..
it takes could be held for quite awhile after the analyze step completes.
Rethink locking of pg_statistic in light of this fact. The original
scheme took an exclusive lock on pg_statistic, which was okay when the
lock could be expected to be released shortly, but that doesn't hold
anymore. Back off to a normal writer's lock (RowExclusiveLock). This
allows concurrent ANALYZE of nonoverlapping sets of tables, at the price
that concurrent ANALYZEs of the same table may fail with 'tuple
concurrently updated'.
> Looks like Alvaro got sideswiped by the system catalog indexing changes
> I made over the weekend. It's a simple change, just reduce the whole
> mess to a "CatalogUpdateIndexes()" call.
I update two tuples, so I manually CatalogOpenIndexes() and
CatalogIndexInsert() two times, as per comments in
CatalogUpdateIndexes().
I also removed a couple of useless CommandCounterIncrement(), some
useless definitions in src/include/commands/cluster.h and useless
includes in src/backend/commands/cluster.c. This version passes the
regression test I had made for previous versions.
Alvaro Herrera
> l.mode, l.isgranted from pg_lock_info() as l(relation oid, database oid,
> backendpid int4, mode text, isgranted bool);
> ERROR: badly formatted planstring "COLUMNDEF "...
>
Reported by Neil Conway -- I never implemented readfuncs.c support for
ColumnDef or TypeName, which is needed so that views can be created on
functions returning type RECORD. Here's a patch.
Joe Conway
relfilenode.
I sent the CLUSTER patch a few days ago and I think it was missed. I
append it again, this time including the regression test files. For the
committer, please note that you have to cvs add the files as they don't
exist. Maybe add to the parallel and serial schedules also, but I don't
know such stuff.
Alvaro Herrera (<alvherre[a]atentus.com>)
error handling, and simplifies the code that remains. Apparently,
the code that left Berkeley had a whole "error handling subsystem",
which exceptions and whatnot. Since we don't use that anymore,
there's no reason to keep it around.
The regression tests pass with the patch applied. Unless anyone
sees a problem, please apply.
Neil Conway
has_language_privilege, has_schema_privilege to let SQL queries test
all the new privilege types in 7.3. Also, add functions pg_table_is_visible,
pg_type_is_visible, pg_function_is_visible, pg_operator_is_visible,
pg_opclass_is_visible to test whether objects contained in schemas are
visible in the current search path. Do some minor cleanup to centralize
accesses to pg_database, as well.
to behave according to SQL92 (or according to my current understanding
of same, anyway). Per pghackers discussion way back in March 2002:
thread 'Do FROM items of different schemas conflict?'
correctly, truncate to NAMEDATALEN where needed, allow whitespace
around dots in qualified identifiers. Get rid of T_RECFIELD and
T_TGARGV token categories, which weren't accomplishing anything
except to create room for sins of omission in the grammar, ie,
places that should have allowed them and didn't. Fix a few other
bugs en passant.
