Re: md5 hash on table row

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> On Wed, Nov 02, 2005 at 06:07:45PM +0100, A. Kretschmer wrote:
>> is 'record_out()' new in 8.1?

> The signature has changed over time:

> 7.3 record_out(record)
> 7.4 record_out(record)
> 8.0 record_out(record,oid)
> 8.1 record_out(record)

BTW, the addition of OID to the signature was a bad idea (read security
hole), and the more recent 8.0.* subreleases ignore it. So you can just
pass a zero instead of worrying about figuring out the right type OID.
Indeed, Michael's example is formally wrong:

SELECT id, textin(record_out(row(foo), tableoid)) FROM foo;

What record_out is getting here is not a foo; it's a record type that
contains one column that is a foo. Since tableoid is the type of foo,
it does not correctly describe the record. This example would probably
crash an 8.0.0 server, because it would believe the OID argument :-(

Here's the CVS log entry:

2005-04-30 16:04 tgl

* src/backend/utils/adt/rowtypes.c (REL8_0_STABLE): Make record_out
and record_send extract type information from the passed record
object itself, rather than relying on a second OID argument to be
correct. This patch just changes the function behavior and not the
catalogs, so it's OK to back-patch to 8.0. Will remove the
now-redundant second argument in pg_proc in a separate patch in
HEAD only.

and for 8.1 we did this:

2005-05-01 14:56 tgl

* doc/src/sgml/ref/create_type.sgml,
src/backend/access/common/printtup.c,
src/backend/bootstrap/bootstrap.c, src/backend/commands/copy.c,
src/backend/commands/typecmds.c, src/backend/executor/spi.c,
src/backend/nodes/print.c, src/backend/tcop/fastpath.c,
src/backend/utils/adt/arrayfuncs.c,
src/backend/utils/adt/rowtypes.c,
src/backend/utils/adt/ruleutils.c, src/backend/utils/adt/varlena.c,
src/backend/utils/cache/lsyscache.c, src/backend/utils/misc/guc.c,
src/include/utils/lsyscache.h, src/pl/plperl/plperl.c,
src/pl/plpgsql/src/pl_exec.c, src/pl/tcl/pltcl.c: Change CREATE
TYPE to require datatype output and send functions to have only one
argument. (Per recent discussion, the option to accept multiple
arguments is pretty useless for user-defined types, and would be a
likely source of security holes if it was used.) Simplify call
sites of output/send functions to not bother passing more than one
argument.

regards, tom lane