[BUGS] BUG #2369: pg_dump function dependencies
The following bug has been logged online: Bug reference: 2369 Logged by: Jonathan Ellis Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: linux Description:pg_dump function dependencies Details: I have many many instances of these two problems in pg_dump's output: 1) function code don't seem to be taken into account for dependencies for example, one function was dumped as follows (note the %TYPE use), but the general_permissions table was dumped much later: CREATE FUNCTION all_users_permission_id(character varying, integer, character varying) RETURNS integer AS $_$ DECLARE v_permission_type alias for $1; v_on_what_id alias for $2; v_on_which_table alias for $3; v_permission_id general_permissions.permission_id%TYPE; non-%TYPE uses get ignored too; e.g. a function containing this line, before the minions_power_v view was created: ttt := ttt + max(0, coalesce( (0.661 * (select sum(w.value) from weapons_v w where w.party_id = $1 and w.minion_id is not null) - (select sum(tp_total) from minions_power_v m where m.party_id = $1))::int , 0)); ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2370: 25P02,current transaction is aborted, commands ignored until end of transaction block
The following bug has been logged online: Bug reference: 2370 Logged by: Amaresh Wakkar Email address: [EMAIL PROTECTED] PostgreSQL version: 8.X Operating system: Windows XP Description:25P02,current transaction is aborted, commands ignored until end of transaction block Details: Deal all, I am trying to port my application from MySql to PostgreSQL 8.X. It seems PostgreSQL does not give full control to programmer even when they have opted to handle the transaction themselves by setting AUTOCOMMIT=FALSE in code. Scenario: 1.Several records are to be inserted in different tables as a result of taking an order via web form. This activity must be atomic i.e it must succeed or fail completely. 2. Autocommit is set to off before an anonymous transaction is started in JDBC. 3.In one of the inserts we must ignore the failure due to duplicate rows i.e Error state 23505 and continue with remainder set of inserts. Presence of duplicate rows will not be treated as an error condition in this context and system must function normally without aborting the whole transaction (This is what PostgreSQL is doing currently after first failure I get 25P02 and all other inserts are ignored completely). I get following error: org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block Technical details: I don't think this is specific to hardware/software version I am currently using but giving here for the sake of completeness: PostgreSQL version tried : 8.1.3 and 8.0, 8.0.1 JDBC: 8.2dev-501.jdbc3, 8.0-315.jdbc3, 8.1-404.jdbc3 JDK: 1.4 and 1.5 OS: Windows XP Case: The general expectation is that when a programmer is setting autocommit explicitly to off then they want to be in control of the transactions and 'THEY' should decided when to rollback or commit instead of others. This is the case with Oracle, SQL Server and MySQL and I think this is a fair expectation. I am sure this is fairly common scenario with people who do frequent backend coding. I went through archives as it seems this was not a problem in version 8.0.1, unfortunately I have tried with 3 different 8.x.x versions available and similarly for JDBC drivers and the problem/condition still exists. By looking at the error code 25P02, I feel this may not be treated as problem/error by PostgreSQL community. What is the work-around in such event? In my opinion, if there are reasons to throw 25P02 and abort transaction unilaterally, then there are also good reasons not to abort it and let programmer take the decision. A switching mechanism would have been ideal. Any help/suggestion much appreciated!!! Best regards, Amaresh Wakkar ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2369: pg_dump function dependencies
"Jonathan Ellis" <[EMAIL PROTECTED]> writes: > I have many many instances of these two problems in pg_dump's output: > 1) function code don't seem to be taken into account for dependencies No, it isn't, and this should not matter because pg_dump takes care to turn off check_function_bodies. If you have an actual problem, you need to exhibit it, not just claim there is a problem. BTW, what was the other problem? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2370: 25P02,current transaction is aborted, commands ignored until end of transaction block
Amaresh Wakkar wrote: > 3.In one of the inserts we must ignore the failure due to duplicate rows i.e > Error state 23505 and continue with remainder set of inserts. Presence of > duplicate rows will not be treated as an error condition in this context and > system must function normally without aborting the whole transaction (This > is what PostgreSQL is doing currently after first failure I get 25P02 and > all other inserts are ignored completely). I get following error: > > org.postgresql.util.PSQLException: ERROR: current transaction is aborted, > commands ignored until end of transaction block Sure. You can set a SAVEPOINT before trying the insert; if it fails, ROLLBACK TO said savepoint and you can continue merrily with the rest of your transaction. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
