I am seeing a minor error and curious to learn if it is user error or a bug. I have a function (using 8.1devel) that returns a set of rows listing the sizes of the various components of a relation (indices, toast, etc). Here's an example of a successful call: select * from relation_size_components('fat') as (index_size bigint, data_size bigint, total_size bigint, relname name, relkind \"char\", relid oid, relfilenode oid)" index_size | data_size | total_size | relname | relkind | relid | relfilenode ------------+-----------+------------+----------------------+---------+-------+------------- 2088960 | 65536 | 2891776 | fat | r | 59383 | 59383 32768 | 704512 | 737280 | pg_toast_59383 | t | 59386 | 59386 0 | 32768 | 32768 | pg_toast_59383_index | i | 59388 | 59388 0 | 2039808 | 2039808 | fat_idx | i | 59389 | 59389 0 | 49152 | 49152 | fat_uidx | i | 59911 | 59911 (5 rows) The relkind column comes directly from pg_class.relkind, which shows up in "\d pg_class" as type "char" (with the double quotes, unlike the other pg_class attributes). If I remove the escapes and quotes around "char" in the destination attribute list above, select * from relation_size_components('fat') as (index_size bigint, data_size bigint, total_size bigint, relname name, relkind char, relid oid, relfilenode oid)" I get the following error: ERROR: query-specified return row and actual function return row do not match I've traced this to around line 380 of nodeFunctionscan.c, where it thinks the destination attribute for relname has been dropped (attisdropped = true) when I use plan old char instead of "char" as the column type. I ask because it seems like "char" and char should match as type names, but don't. Ed ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings