The example code below assumes you have a “customer_cus” table and a “customer_archive_cua” table with at least two fields. It is a good idea to add a timestamp field to the archive table with DEFAULT now(), so that the date of deletion is captured.

CREATE FUNCTION archive_customer() RETURNS TRIGGER AS '
BEGIN
INSERT INTO customer_archive_cua (name_cua, address_cua)
VALUES (OLD.name_cus,OLD.address_cus);
RETURN NULL;
END;
' LANGUAGE 'plpgsql';
CREATE TRIGGER customer_archive_on_delete AFTER DELETE ON customer_cus
FOR EACH ROW EXECUTE PROCEDURE archive_customer();


References

• PostgreSQL (2nd Edition) (Developer’s Library)

Best method from Dan Lyke: Apache::DBI will pool across Perl programs, and you don’t have to change anything in your scripts.

Next best method from Gilles DAROLD: in your perl script use the following code

use vars qw($dbh);

$dbh ||= DBI::connect($datasrc, $dbuser, $dbpwd);

These can be use to create a database connection class in Perl that can handle transparently the connection / reconnection and disconnection for your code. The end use code doesn’t have to be OO, thus the connection object can be reused in any legacy code.

UPDATE pg_database SET datdba=(SELECT usesysid FROM pg_shadow WHERE usename='new_owner') WHERE datname='db_name';

http://archives.postgresql.org/pgsql-admin/2003-07/msg00301.php

    * From: Tom Lane
    * To: Devrim GUNDUZ
    * Subject: Re: changing ownership of db
    * Date: Tue, 29 Jul 2003 17:41:08 -0400

Devrim GUNDUZ  writes:
> On Tue, 29 Jul 2003, Benjamin Thelen (CCGIS) wrote:
>> I would like to change the ownership of a database.

> UPDATE pg_database SET datdba=(SELECT usesysid FROM pg_shadow WHERE
> usename='new_owner') WHERE datname='db_name';

That is all you need to do --- it's the only place CREATE DATABASE
records the owner's identity.

> If you also want to change the owner of the tables, update pg_class:

> UPDATE pg_class SET relowner=(SELECT usesysid FROM pg_shadow WHERE
> usename='new_owner')  WHERE relname IN (SELECT relname from
> pg_class WHERE relname NOT LIKE 'pg_%');

This is likely to be a very bad idea, especially if you give ownership
of the system tables to a non-superuser.  Ownership of those tables
stays with the postgres user during a CREATE DATABASE.

			regards, tom lane

• Open CFMX administrator
• Click on “Data Sources”
• In the “add new datasource” write in a name and select “other” before clicking “add”
• Fill our the fields as follows:

  CF Data Source Name: JDBC
  URL: jdbc:postgresql://DB_server_fqdn:5432/ (as per Pedro's comment)
  Driver Class: org.postgresql.Driver
  Driver Name: PostgreSQL
  Username: db_user_name
  Password: ******
  Description:
  

• Click submit
• Test connection (Status shoudl say “OK”)

CREATE TABLE temp AS SELECT DISTINCT ON (email) * FROM table_to_deduplicate;
DROP TABLE table_to_deduplicate;
ALTER TABLE temp RENAME TO table_to_deduplicate;

Be mindful of the fact that this process will not preserve the constraints on the original table. So if you have indexes, NOT NULL attributes, primary keys, foreign keys, you’ll have to recreate them.

CREATE TABLE temp AS SELECT DISTINCT * FROM table_to_deduplicate;
DROP TABLE table_to_deduplicate;
ALTER TABLE temp RENAME TO table_to_deduplicate;

Be mindful of the fact that this process will not preserve the constraints on the original table. So if you have indexes, NOT NULL attributes, primary keys, foreign keys, you’ll have to recreate them.

sed -e 's/tt/t\Nt/g' -e 's/t$/t\N/g' -e 's/tt/t\Nt/g' db2_file > pg_file

Conversely, to convert from PostgreSQL to DB2 style, with TAB delimited data:

sed -e 's/t\Nt/tt/g' -e 's/t\N$/t/g' -e 's/t\Nt/tt/g' db2_file > pg_file

The reason we need to go with 3 steps is the following:

• step 1: convert TAB NULL TAB
• step2: convert TAB NULL at the end of line
• step3: convert TAB NULL TAB from sequences where originally there was TAB NULL TAB NULL

All this has been tested on AIX and Linux.

Workaround for PostgreSQL DSN Config Bug

How to fix a bug for PostgreSQL Data Source configuration in the ColdFusion MX Administrator.

The author discovered the solution on this CFTALK thread. The problem is that when configuring a PostgreSQL DSN according to the instructions in this TechNote, if you choose a Driver Name field of PostgreSQL, then that will trigger ColdFusion to invoke a handler template of postgresql.cfm. This handler template is defined in the configuration file neo-query.xml in ColdFusion MX’s lib directory. At one time the ColdFusion MX Administrator was going to provide a PostgreSQL JDBC driver out of the box, and that was partially implemented. However, the postgresql.cfm handler file was never implemented or even created. The result is that after first creating the datasource, when you return to edit it again ColdFusion will recognize the Driver Name of PostgreSQL and attempt to trigger the postgresql.cfmhandler. This causes the error:

"File not found: /CFIDE/administrator/datasources/postgresql.cfm
The specific sequence of files included or processed is:
C:\CFusionMX\wwwroot\CFIDE\administrator\datasources\postgresql.cfm "

The solution in the CFTALK thread shows how to change the handler reference from postgresql.cfm to default.cfm. Then restart ColdFusion MX. You will then be able to edit the datasource correctly. Click Here for the interactive RoboHelp (Demo).
Pete Freitag pointed out in a comment that a better solution would be to find the default.cfm then make a copy named postgresql.cfm.