From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Converting plpgsql to use DTYPE_REC for named composite types
Date: Fri, 29 Dec 2017 22:39:05 -0500
Message-ID: <18011.1514605145@sss.pgh.pa.us> (raw)
In-Reply-To: <23537.1514589378@sss.pgh.pa.us>
References: <8962.1514399547@sss.pgh.pa.us>
<23537.1514589378@sss.pgh.pa.us>
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
Attachments:
[text/x-diff] use-dtype-rec-docs.patch (1.9K, ../18011.1514605145@sss.pgh.pa.us/2-use-dtype-rec-docs.patch)
download | inline diff:diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgmlindex 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 ----
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: Converting plpgsql to use DTYPE_REC for named composite types
In-Reply-To: <18011.1514605145@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox