Barry Lind

after writing/unpinning it.  An actual failure is unlikely, unless the
system is tremendously short of buffers ... but a bug is a bug.

for speed.

Jan

do anything yet, but it has the necessary connections to initialization
and so forth.  Make some gestures towards allowing number of blocks in
a relation to be BlockNumber, ie, unsigned int, rather than signed int.
(I doubt I got all the places that are sloppy about it, yet.)  On the
way, replace the hardwired NLOCKS_PER_XACT fudge factor with a GUC
variable.

message clean up.

confusing definitions in it.

Now the version is 7.01.0006.

directly, rather than through SetConfigOption().

directly, rather than through SetConfigOption().

IS TRUE, etc, with some degree of verisimilitude.  Split out
selectivity support functions from builtins.h into a new header
file selfuncs.h, so as to reduce the number of header files builtins.h
must depend on.  Fix a few missing inclusions exposed thereby.
From Joe Conway, with some kibitzing from Tom Lane.

Here is a patch which inspired by Michael Stephens that should work

Dave Cramer

message in that case.

> > secure_ctx changes too.  it will be PGC_BACKEND after '-p'.
>
> Oh, okay, I missed that part.  Could we see the total state of the
> patch --- ie, a diff against current CVS, not a bunch of deltas?
> I've gotten confused about what's in and what's out.

Ok, here it is.  Cleared the ctx comment too - after -p
it will be PGC_BACKEND in any case.

Marko Kreen

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

sequence.

Alex Pilosov

Jan

it's hard to keep such massive changes in sync with the tree
so I need to get it in and work from there now).

Jan

to large tables.  Recommend ANALYZE or VACUUM ANALYZE after populating
a table.

oid values.

other than tablename_pkey.