2009/6/4 Oleg Bartunov :
> On Wed, 3 Jun 2009, Tom Lane wrote:
>
>> Oleg Bartunov writes:
>>>
>>> seems I don't understand how FOUND variable in pl/pgsql function defined,
>>> when I use EXECUTE of PERFORM. There is no problem when I use plain SQL.
>>
>> EXECUTE doesn't affect FOUND, even if the s
On Wed, 3 Jun 2009, Tom Lane wrote:
Oleg Bartunov writes:
seems I don't understand how FOUND variable in pl/pgsql function defined,
when I use EXECUTE of PERFORM. There is no problem when I use plain SQL.
EXECUTE doesn't affect FOUND, even if the statement-to-be-executed would
have. There's
Oleg Bartunov writes:
> seems I don't understand how FOUND variable in pl/pgsql function defined,
> when I use EXECUTE of PERFORM. There is no problem when I use plain SQL.
EXECUTE doesn't affect FOUND, even if the statement-to-be-executed would
have. There's been some discussion about changing
Are you not confused somewhere??
First you insert INSERT INTO db VALUES(1,'one');
Then you do this :
SELECT merge_db(1, 'two');
But for some reason this SQL select * from db; selects two for your
text field...
Ries
On Jun 3, 2009, at 2:42 PM, Oleg Bartunov wrote:
Hi there,
seems I don
Hi there,
seems I don't understand how FOUND variable in pl/pgsql function defined,
when I use EXECUTE of PERFORM. There is no problem when I use plain SQL.
Below is a test I did for 8.4beta2. This is simplified script and I can
use plain SQL, but in my project I need EXECUTE.
CREATE TABLE db
2008/6/27 A B <[EMAIL PROTECTED]>:
> Thanks for the suggestion on GET DIAGNOSTICS.
>
> But concerning EXECUTE, if I do
>
> BEGIN
> EXECUTE QueryA
> EXCEPTION WHEN OTHERS THEN
> QueryB
> END;
>
>
> will it execute QueryB if QueryA fails?
yes, but it's not preferable way. It creates subtran
Thanks for the suggestion on GET DIAGNOSTICS.
But concerning EXECUTE, if I do
BEGIN
EXECUTE QueryA
EXCEPTION WHEN OTHERS THEN
QueryB
END;
will it execute QueryB if QueryA fails?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscripti
2008/6/27 A B <[EMAIL PROTECTED]>:
>> I think you'd be well advised to rethink your table layout so you don't
>> need so much dynamic SQL. The above is going to suck on both
>> performance and readability grounds, and it doesn't look like it's
>> accomplishing anything you couldn't do by combining
> I think you'd be well advised to rethink your table layout so you don't
> need so much dynamic SQL. The above is going to suck on both
> performance and readability grounds, and it doesn't look like it's
> accomplishing anything you couldn't do by combining all the Rating
> tables into one table
"A B" <[EMAIL PROTECTED]> writes:
> CREATE OR REPLACE FUNCTION addRating(tbl_ INTEGER,value_ INTEGER)
> RETURNS void AS $$
> DECLARE
> tablename TEXT;
> fieldname TEXT;
> BEGIN
> tablename:='Rating_'||tbl_;
> fieldname:='val';
> EXECUTE 'UPDATE '||tablename||' SET '||f
Hi.
I run a function
CREATE OR REPLACE FUNCTION addRating(tbl_ INTEGER,value_ INTEGER)
RETURNS void AS $$
DECLARE
tablename TEXT;
fieldname TEXT;
BEGIN
tablename:='Rating_'||tbl_;
fieldname:='val';
EXECUTE 'UPDATE '||tablename||' SET '||fieldname||'='||value
11 matches
Mail list logo
