Please let me know what's wrong with below code
CREATE LANGUAGE plpgsql;
create or replace FUNCTION test_cu( p_cursor REFCURSOR) returns REFCURSOR
AS $procedure$
BEGIN
open p_cursor FOR
select * from test;
RETURN p_cursor;
END; $procedure$
LANGUAGE plpgsql;
create or replace FUNCTI
On 05/24/2010 01:29 AM, Grzegorz Jaśkiewicz wrote:
don't lock tables explicitly. That's a killer for (concurrent) performance.
Just write queries properly, and use appropriate transaction level.
And you are sorted.
Read Committed is fine, as long as I restart the UPDATE query RETURNING
nothing.
On 24/05/10 02:51, Ken Winter wrote:
How can I write a PL/PgSQL function that rolls back every database
change it has done?
Have it raise an exception, causing the surrounding transaction to
terminate with an error.
Another function calling yours can still catch the exception and handle
it,
don't lock tables explicitly. That's a killer for (concurrent) performance.
Just write queries properly, and use appropriate transaction level.
And you are sorted.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
How can I write a PL/PgSQL function that rolls back every database change it
has done?
I'm about to write a set of database test functions. Each function needs to
do some INSERT, UPDATE, or DELETE actions, test whether they had their
intended effect, and then roll back the test changes to rest
On 05/23/2010 08:19 PM, Tom Lane wrote:
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
find in docs part that talks about transaction isolation levels, and
translate it to your problem.
Yes, please read the fine manual:
http://www.postgresql.org/docs/8.4/static/mvcc.html
What I think will happ
On 05/22/2010 09:40 PM, Ivan Voras wrote:
Hello,
I have a schema which tracks various pieces of information which would
need to be globally searchable. One approach I came up with to make all
of the data searchable is to create a view made of UNION ALL queries
that would integrate different tabl
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
> find in docs part that talks about transaction isolation levels, and
> translate it to your problem.
Yes, please read the fine manual:
http://www.postgresql.org/docs/8.4/static/mvcc.html
What I think will happen in your example is that all concurren
by default query is wrapped in a transaction (if it is not run under a
transaction). And this will be default transaction isolation level.
some people think it works magic, but that's not true.
find in docs part that talks about transaction isolation levels, and
translate it to your problem.
--
S
On 05/23/2010 03:15 PM, Grzegorz Jaśkiewicz wrote:
every single query in postrgresql runs as a transaction, on top of it,
some are atomic, like when you use RETURNING statement. This is
because postgresql doesn't actually have to select these rows as
separate query.
Please note the cooperation
every single query in postrgresql runs as a transaction, on top of it,
some are atomic, like when you use RETURNING statement. This is
because postgresql doesn't actually have to select these rows as
separate query.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make cha
On Sat, May 22, 2010 at 11:06:02PM -0400, Stephen Frost wrote:
> * Luis Daniel Lucio Quiroz (luis.daniel.lu...@gmail.com) wrote:
> > 1. whar are equivalent for these commands:
> > in mysql: mysqldump mydata_base_name
>
> pg_dump (pg_restore to restore from the dump, if you use a non-SQL
> format
12 matches
Mail list logo
