overlooked in 7.3 updates.  Not a critical fix but avoids a notice when
the resulting SQL script is executed.

with OPAQUE, as per recent pghackers discussion.  I still want to do some
more work on the 'cstring' pseudo-type, but I'm going to commit the bulk
of the changes now before the tree starts shifting under me ...

Gilles DAROLD

Oracle database to PostgreSQL.

    It currently dump the database schema (tables, views, sequences,
    indexes, grants), with primary, unique and foreign keys into PostgreSQL
    syntax without editing the SQL code generated. You can dump only a
    particular schema from the Oracle database.

    Functions, procedures and triggers with SQL or PLSQL code generated must
    be reviewed to match the PostgreSQL syntax. Some usefull recommandation
    on porting Oracle to PostgreSQL can be found at
http://techdocs.postgresql.org/
    under the "Converting from other Databases to PostgreSQL" Oracle part. I
just
    notice one thing more is that the trunc() function in Oracle is the same for
number
    or date so be carefull when porting to PostgreSQL to use trunc() for number
and
    date_trunc() for date.

I will add more precision in type NUMBER conversion based on length to match
as closest as possible all rich PostgreSQL numerics type. But it seems not to be

urgent as it seems that Oracle DBAs only create number with length 22 (default)
Space seems not to be their problem...

Gilles DAROLD