Adrian Klaver wrote:
If you are using Postgres 8.1+ then it becomes even easier because you can use OUT parameters
in the function argument list to eliminate the "as test(c1 int,c2 int)" clause. At
this point it becomes a A-->B-->C problem i.e determine what your inputs are, how you
want to
- "Peter Willis" wrote:
> Adrian Klaver wrote:
> > On Friday 03 April 2009 6:51:05 am Adrian Klaver wrote:
> >> On Thursday 02 April 2009 6:16:44 pm Adrian Klaver wrote:
> >>> Now I remember. Its something that trips me up, the RECORD in
> RETURN
> >>> setof RECORD is not the same thing as t
Adrian Klaver wrote:
On Friday 03 April 2009 6:51:05 am Adrian Klaver wrote:
On Thursday 02 April 2009 6:16:44 pm Adrian Klaver wrote:
Now I remember. Its something that trips me up, the RECORD in RETURN
setof RECORD is not the same thing as the RECORD in DECLARE RECORD. See
below for a better
On Friday 03 April 2009 6:51:05 am Adrian Klaver wrote:
> On Thursday 02 April 2009 6:16:44 pm Adrian Klaver wrote:
> > Now I remember. Its something that trips me up, the RECORD in RETURN
> > setof RECORD is not the same thing as the RECORD in DECLARE RECORD. See
> > below for a better explanation
On Thursday 02 April 2009 6:16:44 pm Adrian Klaver wrote:
>
>
> Now I remember. Its something that trips me up, the RECORD in RETURN setof
> RECORD is not the same thing as the RECORD in DECLARE RECORD. See below for
> a better explanation-
> http://www.postgresql.org/docs/8.3/interactive/plpgsql-d
On Thursday 02 April 2009 4:22:06 pm Peter Willis wrote:
> Adrian Klaver wrote:
> > Did you happen to catch this:
> > Note that functions using RETURN NEXT or RETURN QUERY must be called as a
> > table source in a FROM clause
> >
> > Try:
> > select * from test_function(1)
>
> I did miss that, but
Adrian Klaver wrote:
Did you happen to catch this:
Note that functions using RETURN NEXT or RETURN QUERY must be called as a table
source in a FROM clause
Try:
select * from test_function(1)
I did miss that, but using that method to query the function
didn't work either. Postgres doesn't s
- "Peter Willis" wrote:
> Adrian Klaver wrote:
> > On Wednesday 01 April 2009 4:31:20 pm Peter Willis wrote:
> >> Hello,
> >>
> >> I am having a problem with a FUNCTION.
> >> The function creates just fine with no errors.
> >>
> >> However, when I call the function postgres produces an err
Adrian Klaver wrote:
On Wednesday 01 April 2009 4:31:20 pm Peter Willis wrote:
Hello,
I am having a problem with a FUNCTION.
The function creates just fine with no errors.
However, when I call the function postgres produces an error.
Perhaps someone can enlighten me.
--I can reproduce the e
On Wednesday 01 April 2009 4:31:20 pm Peter Willis wrote:
> Hello,
>
> I am having a problem with a FUNCTION.
> The function creates just fine with no errors.
>
> However, when I call the function postgres produces an error.
>
> Perhaps someone can enlighten me.
>
>
> --I can reproduce the error by
Hello,
I am having a problem with a FUNCTION.
The function creates just fine with no errors.
However, when I call the function postgres produces an error.
Perhaps someone can enlighten me.
--I can reproduce the error by making a test function
--that is much easier to follow that the original:
"geraldo" <[EMAIL PROTECTED]> writes:
> Can anybody tell me why the following code when activated
> by a select only affects the first line of the table???
> create or replace function increase(integer)
> returns void as 'update tab set price=price*(1+$1/100.0)'
> language sql;
Works fine here.
Can anybody tell me why the following code when activated
by a select only affects the first line of the table???
create or replace function increase(integer)
returns void as 'update tab set price=price*(1+$1/100.0)'
language sql;
Thanks.
---(end of broadcast)
13 matches
Mail list logo
