Re: pl/pgsql breakage in 8.1b4?

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.

In response to

Responses

Browse pgsql-hackers by date

  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)