Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: RFD: Don't force plpgsql IN parameters to constant
- From: Steve Prentice <prentice(at)cisco(dot)com>
- To: Robert Haas <robertmhaas(at)gmail(dot)com>
- Cc: pgsql-hackers(at)postgresql(dot)org
- Subject: Re: RFD: Don't force plpgsql IN parameters to constant
- Date: Wed, 29 Jul 2009 18:05:17 -0700
- Message-id: <E0C44496-8477-4378-AD3B-678D1D2CB914@cisco.com> <text/plain>
On Jul 29, 2009, at 5:26 PM, Robert Haas wrote:
Wow. I can imagine about a thousand ways that this could break existing applications. I would not be prepared to bet a dollar that anything I've written would survive the impact unscathed. I have a feeling someone else is going to shoot you out of the water completely, but all I'll say is it would definitely need to be OPTIONAL.
I guess I don't get how it would break existing applications. All of the regression tests pass. The parameters are passed as a copy, so it can't modify your variable that you pass in. Perhaps I'm missing something--can you elaborate on how this would break existing applications?
-Steve
- Follow-Ups:
- Re: RFD: Don't force plpgsql IN parameters to constant
- From: Robert Haas
- Re: RFD: Don't force plpgsql IN parameters to constant
- References:
- RFD: Don't force plpgsql IN parameters to constant
- From: Steve Prentice
- Re: RFD: Don't force plpgsql IN parameters to constant
- From: Robert Haas
- RFD: Don't force plpgsql IN parameters to constant
- Prev by Date: Re: improvements for dict_xsyn extended synonym dictionary - RRR
- Next by Date: Re: RFD: Don't force plpgsql IN parameters to constant
- Previous by thread: Re: RFD: Don't force plpgsql IN parameters to constant
- Next by thread: Re: RFD: Don't force plpgsql IN parameters to constant
- Indexes: