From: | Philip Yarra <philip(at)utiba(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pl/pgsql breakage in 8.1b4? |
Date: | 2005-10-28 04:55:21 |
Message-ID: | 200510281455.22264.philip@utiba.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 28 Oct 2005 02:10 pm, Tom Lane wrote:
> > Without really wishing to volunteer myself: should plpgsql allow using
> > parameters with the same name as the columns being referred to within the
> > function, provided they're qualified as function_name.parameter?
>
> No, because that just changes where the ambiguity is. The function name
> could easily conflict with a table name.
Yup, I guess it could.
> It's a mighty weird-looking
> convention anyway --- on what grounds would you argue that the function
> is a structure having parameter names as fields?
I wasn't arguing either way, I was just curious.
Hmmm... is it feasible to make the error message a little more useful? People
who didn't use the old-style positional parameters might not understand where
$1 and $2 are coming from.
Regards, Philip.
-----------------
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-10-28 04:58:30 | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89) |
Previous Message | Tom Lane | 2005-10-28 04:44:06 | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89) |