Re: [PERFORM] COPY FROM performance improvements

"Alon Goldshuv" <agoldshuv@greenplum.com> writes:
>> This patch appears to reverse out the most recent committed changes in
>> copy.c.

> Which changes do you refer to? I thought I accommodated all the recent
> changes (I recall some changes to the tupletable/tupleslot interface, HEADER
> in cvs, and hex escapes and maybe one or 2 more). What did I miss?

The latest touch of copy.c, namely this patch:

2005-07-10 17:13  tgl

    * doc/src/sgml/ref/create_type.sgml, src/backend/commands/copy.c,
    src/backend/commands/typecmds.c, src/backend/tcop/fastpath.c,
    src/backend/tcop/postgres.c, src/backend/utils/adt/arrayfuncs.c,
    src/backend/utils/adt/date.c, src/backend/utils/adt/numeric.c,
    src/backend/utils/adt/rowtypes.c,
    src/backend/utils/adt/timestamp.c, src/backend/utils/adt/varbit.c,
    src/backend/utils/adt/varchar.c, src/backend/utils/adt/varlena.c,
    src/backend/utils/mb/mbutils.c, src/include/catalog/catversion.h,
    src/include/catalog/pg_proc.h,
    src/test/regress/expected/type_sanity.out,
    src/test/regress/sql/type_sanity.sql: Change typreceive function
    API so that receive functions get the same optional arguments as
    text input functions, ie, typioparam OID and atttypmod.  Make all
    the datatypes that use typmod enforce it the same way in typreceive
    as they do in typinput.  This fixes a problem with failure to
    enforce length restrictions during COPY FROM BINARY.

It was rather obvious, given that the first chunk of the patch backed up
the file's CVS version stamp from 1.247 to 1.246 :-(

            regards, tom lane