Re: revised patch for PL/PgSQL table functions

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: revised patch for PL/PgSQL table functions
Date: 2002-09-01 07:44:19
Message-ID: 87k7m6w3vw.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Actually, it does that already: exec_stmt_return_next relies on the
> expectedDesc to check the value being output in all cases. So for a
> SETOF RECORD function, the additional work required might be as simple
> as just opening up the check in plpgsql_compile to allow RECORD return
> type. For the non-SETOF case (table function returning a single tuple),
> I think exec_stmt_return would work okay as long as plpgsql_compile had
> set fn_retistuple true for RECORD.

Okay, here's a patch that implements this -- no additional changes to
PL/PgSQL were needed, as far as I could tell. I've added some
regression tests that cover this new functionality and they seem to
work as expected.

Unless anyone sees a problem, please apply.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

Attachment Content-Type Size
record_funcs-2.patch text/x-patch 6.3 KB

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2002-09-01 08:00:24 CREATE TABLE docs fix
Previous Message Alvaro Herrera 2002-09-01 07:11:26 reindex in tab completion