Tom Lane wrote:
Is there a reason we force plpgsql IN parameters to constant?
Now having said all that, I'm not really in favor of Steve's
proposal --- it seems like it mostly would be encouraging dubious
programming practices. But it's hard to say that the arguments
against are more than
Tom Lane wrote:
Steve Prentice prent...@cisco.com writes:
On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote:
Tom added a comment in 1995
For the record, I meant 2005.
I was intending to say something like I've been around this project
a long time, but not THAT long ...
I was looking
Is there a reason we force plpgsql IN parameters to constant? The
reason I ask is because having them mutable would go a long way in
easing a port from Informix's SPL. For better or worse, we have a fair
amount of code in SPL that does something like:
-- pObjectId is an IN parameter
Steve Prentice wrote:
Is there a reason we force plpgsql IN parameters to constant? The
reason I ask is because having them mutable would go a long way in
easing a port from Informix's SPL. For better or worse, we have a fair
amount of code in SPL that does something like:
-- pObjectId
On Wed, Jul 29, 2009 at 7:55 PM, Steve Prenticeprent...@cisco.com wrote:
Is there a reason we force plpgsql IN parameters to constant? The reason I
ask is because having them mutable would go a long way in easing a port from
Informix's SPL. For better or worse, we have a fair amount of code in
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
On Jul 29, 2009, at 5:23 PM, Andrew Dunstan wrote:
First reaction is that it would mean we could never pass them by
reference. I know PLPerl uses in effect pass by copy, but what does
PLPgsql do?
Isn't this effectively what we accomplish with an IN/OUT parameter?
--
Sent via
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 29, 2009 at 7:55 PM, Steve Prenticeprent...@cisco.com wrote:
Is there a reason we force plpgsql IN parameters to constant?
Wow. I can imagine about a thousand ways that this could break
existing applications. I would not be prepared to
Andrew Dunstan and...@dunslane.net writes:
First reaction is that it would mean we could never pass them by
reference. I know PLPerl uses in effect pass by copy, but what does
PLPgsql do?
It's not really an issue, because plpgsql keeps track of whether
the current value of the variable
On Wed, Jul 29, 2009 at 9:05 PM, Steve Prenticeprent...@cisco.com wrote:
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
On Wed, Jul 29, 2009 at 9:08 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jul 29, 2009 at 7:55 PM, Steve Prenticeprent...@cisco.com wrote:
Is there a reason we force plpgsql IN parameters to constant?
Wow. I can imagine about a thousand ways that
On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote:
Tom added a comment in 1995
For the record, I meant 2005.
-Steve
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas robertmh...@gmail.com writes:
Hmm, well if I understand this correctly (now), it's similar to allowing:
void
test2(int a)
{
a = 2;
return;
}
...which is a fairly common programming practice that I don't think is
particularly considered bad style, or at least certainly not by
Steve Prentice prent...@cisco.com writes:
On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote:
Tom added a comment in 1995
For the record, I meant 2005.
I was intending to say something like I've been around this project
a long time, but not THAT long ...
regards, tom
14 matches
Mail list logo
