Обсуждение: Int_aggregate/pgstattuple minor fix

The patch below removes attempts to drop objects before creating them
from the int_aggregate and pgstattuple SQL scripts. This causes the
script to fail on databases where the affected objects don't already
exist when the script is executed by the Win32 installer, pgAdmin or any
other interface that executes scripts 'as-is'. None of the other contrib
scripts appear do this.

Please apply.

Regards, Dave


Index: int_aggregate.sql.in
===================================================================
RCS file:
/projects/cvsroot/pgsql-server/contrib/intagg/int_aggregate.sql.in,v
retrieving revision 1.5
diff -u -r1.5 int_aggregate.sql.in
--- int_aggregate.sql.in    14 May 2003 03:25:56 -0000    1.5
+++ int_aggregate.sql.in    1 Oct 2004 13:23:25 -0000
@@ -17,7 +17,7 @@

 -- The aggration funcion.
 -- uses the above functions to create an array of integers from an
aggregation.
-DROP AGGREGATE int_array_aggregate(int4);
+-- DROP AGGREGATE int_array_aggregate(int4);
 CREATE AGGREGATE int_array_aggregate (
     BASETYPE = int4,
     SFUNC = int_agg_state,
Index: pgstattuple.sql.in
===================================================================
RCS file:
/projects/cvsroot/pgsql-server/contrib/pgstattuple/pgstattuple.sql.in,v
retrieving revision 1.8
diff -u -r1.8 pgstattuple.sql.in
--- pgstattuple.sql.in    12 Jun 2003 08:02:53 -0000    1.8
+++ pgstattuple.sql.in    1 Oct 2004 13:30:27 -0000
@@ -1,7 +1,7 @@
 -- Adjust this setting to control where the objects get created.
 SET search_path = public;

-DROP TYPE pgstattuple_type CASCADE;
+-- DROP TYPE pgstattuple_type CASCADE;
 CREATE TYPE pgstattuple_type AS (
     table_len BIGINT,        -- physical table length in
bytes
     tuple_count BIGINT,        -- number of live tuples

"Dave Page" <dpage@vale-housing.co.uk> writes:
> The patch below removes attempts to drop objects before creating them
> from the int_aggregate and pgstattuple SQL scripts. This causes the
> script to fail on databases where the affected objects don't already
> exist when the script is executed by the Win32 installer, pgAdmin or any
> other interface that executes scripts 'as-is'. None of the other contrib
> scripts appear do this.

Seems reasonable.  You could also make the argument that the DROPs
actually risk dropping the wrong object, since they could find a
matching name in the schema search path that is not in the current
schema (and thus not really a conflict).

            regards, tom lane