Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1eV7zN-0003QF-3O
	for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Dec 2017 03:39:13 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1eV7zK-00058w-JM
	for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Dec 2017 03:39:10 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1eV7zK-00058n-9x
	for pgsql-hackers@lists.postgresql.org; Sat, 30 Dec 2017 03:39:10 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1eV7zH-0004R8-4O
	for pgsql-hackers@lists.postgresql.org; Sat, 30 Dec 2017 03:39:08 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vBU3d51U018012
	for <pgsql-hackers@lists.postgresql.org>; Fri, 29 Dec 2017 22:39:05 -0500
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
In-reply-to: <23537.1514589378@sss.pgh.pa.us>
References: <8962.1514399547@sss.pgh.pa.us> <23537.1514589378@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 29 Dec 2017 18:16:18 -0500"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <17969.1514605085.0@sss.pgh.pa.us>
Date: Fri, 29 Dec 2017 22:39:05 -0500
Message-ID: <18011.1514605145@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17969.1514605085.1@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

------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="use-dtype-rec-docs.patch";
	charset="us-ascii"
Content-ID: <17969.1514605085.2@sss.pgh.pa.us>
Content-Description: use-dtype-rec-docs.patch
Content-Transfer-Encoding: quoted-printable

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 res=
ult
       is a row type whose columns are determined by specification in the
       calling query, as discussed in <xref linkend=3D"queries-tablefuncti=
ons"/>.
      </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=3D"queries-tablefuncti=
ons"/>.
      </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</st=
ructname>
      and <structname>table2</structname> are existing tables having at le=
ast the
      mentioned fields:
--- 674,679 ----

------- =_aaaaaaaaaa0--