Josh Berkus j...@agliodbs.com writes:
How much of this pain would go away if we changed over to the arguably
correct (as in Or*cle does it that way) scoping for names, wherein the
parser first tries to match a name against column names of tables of the
current SQL statement, and only failing
How much of this pain would go away if we changed over to the arguably
correct (as in Or*cle does it that way) scoping for names, wherein the
parser first tries to match a name against column names of tables of the
current SQL statement, and only failing that looks to see if they are
On 3/7/09, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying the parameter
On Sun, Mar 8, 2009 at 4:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ryan Bradetich rbradet...@gmail.com writes:
This is one of the things I wanted to start looking at for 8.5.
My idea was to optionally use : or @ (not sure which is more popular) to
specify this token is only a variable.
This
2009/3/9 Ryan Bradetich rbradet...@gmail.com:
On Sun, Mar 8, 2009 at 4:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ryan Bradetich rbradet...@gmail.com writes:
This is one of the things I wanted to start looking at for 8.5.
My idea was to optionally use : or @ (not sure which is more popular) to
On Sat, Mar 7, 2009 at 9:29 PM, Dimitri Fontaine dfonta...@hi-media.comwrote:
In fact, maybe a new option to set the OUT parameters prefix to use from
within the function body would do?
Le 7 mars 09 à 19:56, Dimitri Fontaine a écrit :
CREATE OR REPLACE FUNCTION test_out
(
IN a integer,
Hello Robert,
I have been bitten by this problem many times as well.
I wonder whether it would be possible to make PL/pgsql take :foo to
mean the parameter named foo, and then provide an option to make that
THE ONLY WAY to refer to the parameter foo. For
backward-compatibility, and
Ryan Bradetich rbradet...@gmail.com writes:
This is one of the things I wanted to start looking at for 8.5.
My idea was to optionally use : or @ (not sure which is more popular) to
specify this token is only a variable.
This whole line of thought is really a terrible idea IMHO. plpgsql is
On Fri, Mar 6, 2009 at 8:44 PM, Josh Berkus j...@agliodbs.com wrote:
Robert,
Thing is, anybody can institute their own naming convention. I've long used
v_ as a prefix. Allowing : would save me some keystrokes, but that's about
it.
--Josh
True... but there doesn't seem to be any shortage
It wouldn't be so bad if you could assign internal and external column names.
Within the function you call the column v_foo but the caller of the
function receives column foo instead.
OUT v_foo varchar AS foo
Another alternative is requiring a prefix like plout for the
replacement to occur:
(
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column names.
Within the function you call the column v_foo but the caller of the
function receives column foo instead.
OUT v_foo varchar AS foo
Another
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column names.
This is a good point. Uglifying the parameter names is sort of OK for
input parameters, but is much
2009/3/7 Robert Haas robertmh...@gmail.com:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column names.
Within the function you call the column v_foo but the caller of the
function receives column foo
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying the parameter names is sort of
Gregory Stark st...@enterprisedb.com writes:
I'm not sure that's any better. The case where I've run into this is when I
have something like:
balance := new value
UPDATE tab SET balance = balance
In that case the only way we could get it right is if we default to the local
variable but
actually - function name should be used as label now. This code is working:
Not helpful for me. The most typical conflict I have is actually the
OUT parameter and table name, not a column of the table.
Really don't want to prefix all tables with a hardcoded schema or do
variable substitution
Hello
2009/3/7 Tom Lane t...@sss.pgh.pa.us:
Gregory Stark st...@enterprisedb.com writes:
I'm not sure that's any better. The case where I've run into this is when I
have something like:
balance := new value
UPDATE tab SET balance = balance
In that case the only way we could get it right
On Sat, Mar 7, 2009 at 11:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying
Hello
2009/3/7 Rod Taylor rod.tay...@gmail.com:
actually - function name should be used as label now. This code is working:
Not helpful for me. The most typical conflict I have is actually the
OUT parameter and table name, not a column of the table.
This conflict I never meet. And I afraid
Hi,
Le 7 mars 09 à 02:44, Josh Berkus a écrit :
Thing is, anybody can institute their own naming convention. I've
long used v_ as a prefix. Allowing : would save me some keystrokes,
but that's about it.
What I usually do in those cases is abusing the ALIAS option of
DECLARE (because as
In fact, maybe a new option to set the OUT parameters prefix to use
from within the function body would do?
Le 7 mars 09 à 19:56, Dimitri Fontaine a écrit :
CREATE OR REPLACE FUNCTION test_out
(
IN a integer,
IN b integer,
OUT s integer
)
RETURNS setof integer
SET out_prefix TO 'v_'
Dimitri Fontaine dfonta...@hi-media.com writes:
I'd sure be happy not having to do it explicitly, but schema-style
prefixing has the drawback of needing to avoid any user defined
schema.
No, not really, because it'd be the wrong number of naming levels.
Assuming that we were to switch to
On Sat, Mar 7, 2009 at 11:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying
Robert Haas robertmh...@gmail.com writes:
I think that would definitely be an improvement. Would that mean that
in a query like the following:
SELECT t.id FROM test t WHERE t.id = 17
...it wouldn't consider replacing t? That all by itself would be an
improvement...
It's already the case
On Sat, Mar 7, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think that would definitely be an improvement. Would that mean that
in a query like the following:
SELECT t.id FROM test t WHERE t.id = 17
...it wouldn't consider replacing t?
2009/3/7 Dimitri Fontaine dfonta...@hi-media.com:
In fact, maybe a new option to set the OUT parameters prefix to use from
within the function body would do?
Le 7 mars 09 à 19:56, Dimitri Fontaine a écrit :
CREATE OR REPLACE FUNCTION test_out
(
IN a integer,
IN b integer,
OUT s
Hi
It was one of my worst Friday's finding out that this brain dead
implementation of out parameters had been part of fuck up again.
This time we did notice it two days too late.
I wish for a way to use out parameters in functions only through some
predefined prefix like in triggers new and old.
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja asc...@gmail.com wrote:
It was one of my worst Friday's finding out that this brain dead
implementation of out parameters had been part of fuck up again.
:)
This time we did notice it two days too late.
I wish for a way to use out parameters in
Jonah H. Harris jonah.har...@gmail.com wrote:
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja asc...@gmail.com wrote:
It really sucks what kind of mistakes you can pass to production
unknowingly. I would much prefer a way to prevent such nonsense.
Here was the case where out parameters were with
Kevin Grittner escribió:
I find the PostgreSQL implementation of OUT parameters, well,
surprising. I've used databases where stored procedures can have a
RETURN value, OUT parameters, and result streams as three discreet
things which can't be mistaken for one another -- which seems more
On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja asc...@gmail.com wrote:
It was one of my worst Friday's finding out that this brain dead
implementation of out parameters had been part of fuck up again.
This time we did notice it two days too late.
I wish for a way to use out parameters in functions
Robert,
I wonder whether it would be possible to make PL/pgsql take :foo to
mean the parameter named foo, and then provide an option to make that
THE ONLY WAY to refer to the parameter foo. For
backward-compatibility, and compatibility with (ahem) other database
products, we probably don't
32 matches
Mail list logo
