Thread: rowset-returning function mismatch

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

On Fri, 28 Jan 2005, Ed L. wrote:

> I ask because it seems like "char" and char should match as type names,
> but don't.

Unfortunately, "char" and char are actually different types in
declarations like that AFAIK.  When in quotes it refers to the postgres
single byte single character type, IIRC when not in quotes some magic is
applied in the parser relating to handling CHAR(n).

"Ed L." <pgsql@bluepolka.net> writes:
> I ask because it seems like "char" and char should match as type names,
> but don't.

No, they don't.  char without any quotes is a SQL reserved word that
is equivalent to CHARACTER(1).  "char" with quotes is not a reserved
word, by definition.  For largely historical reasons it happens to match
a single-byte datatype that existed in the deeps of time in PostQUEL,
and is still used in our system catalogs as a sort of poor man's
enumeration type.

Note the different results here:

regression=# create table foo (a char, b "char");
CREATE TABLE
regression=# \d foo
        Table "public.foo"
 Column |     Type     | Modifiers
--------+--------------+-----------
 a      | character(1) |
 b      | "char"       |

regression=#

            regards, tom lane