I wrote:
> I hacked on the domain-support problem a bit and it worked out well,
> so attached is a revised patch that incorporates that. This caused
> me to revise some assumptions about what expandedrecord.c's internal
> invariants ought to be, so it's probably better to look at this as
> a new patch rather than a diff from v1.
Oh, I'd not looked at the documentation angle of this. Here's a short
add-on patch which just adds the fact that "record" is now a valid
argument type, and removes a no-longer-correct claim that system columns
are always inaccessible in row variables.
The documentation draws a distinction between "record" and "row" variables
which is now rather artificial so far as the code is concerned. But it's
not totally pointless either, since it's still true that a variable
declared "record" will mutate its type in a way that a
named-composite-type variable will not. I'm inclined to leave that text
as is; anyone think differently?
regards, tom lane
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 7d23ed4..86d28fb 100644
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
***************
*** 123,129 ****
and they can return a result of any of these types. They can also
accept or return any composite type (row type) specified by name.
It is also possible to declare a <application>PL/pgSQL</application>
! function as returning <type>record</type>, which means that the result
is a row type whose columns are determined by specification in the
calling query, as discussed in <xref linkend="queries-tablefunctions"/>.
</para>
--- 123,131 ----
and they can return a result of any of these types. They can also
accept or return any composite type (row type) specified by name.
It is also possible to declare a <application>PL/pgSQL</application>
! function as accepting <type>record</type>, which means that any
! composite type will do as input, or
! as returning <type>record</type>, which means that the result
is a row type whose columns are determined by specification in the
calling query, as discussed in <xref linkend="queries-tablefunctions"/>.
</para>
*************** user_id users.user_id%TYPE;
*** 672,685 ****
</para>
<para>
- Only the user-defined columns of a table row are accessible in a
- row-type variable, not the OID or other system columns (because the
- row could be from a view). The fields of the row type inherit the
- table's field size or precision for data types such as
- <type>char(<replaceable>n</replaceable>)</type>.
- </para>
-
- <para>
Here is an example of using composite types. <structname>table1</structname>
and <structname>table2</structname> are existing tables having at least the
mentioned fields:
--- 674,679 ----
