| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, darcy(at)wavefire(dot)com |
| Subject: | Re: help with PL/PgSQL bug |
| Date: | 2003-01-11 02:06:29 |
| Message-ID: | 1042250788.743.95.camel@tokyo |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2003-01-10 at 20:28, Tom Lane wrote:
> The core dump appears to occur when the SELECT INTO fails to retrieve
> a row, leaving "finalrec" undefined.
Thanks very much for your help, Tom.
> Clearly, RETURN NEXT with an undefined record variable shouldn't dump
> core, but what should it do? Raise an error, or perhaps be a no-op?
I'd vote for making it a no-op. Raising an error is too severe for a
fairly routine occurence, IMHO. If we make it a no-op, it's consistent
with how I understand a SELECT INTO of 0 rows -- it doesn't produce an
"undefined value", but an "empty result set" (like the difference
between "" and a NULL pointer).
Cheers,
Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-01-11 02:13:26 | Re: help with PL/PgSQL bug |
| Previous Message | Laurette Cisneros | 2003-01-11 01:50:06 | Re: 7.3 pg_dump with -Fc option crashes |