On Sun, Dec 9, 2012 at 9:20 PM, Zbigniew wrote:
> Hello,
>
> As I read while googling the web, many people complained about this
> before. Couldn't it be made optional (can be even with "default ON")?
> I understand, that there are situations, when it is a must - for
> example, when the rest of qu
On Dec 11, 2012, at 6:48, Zbigniew wrote:
> 2012/12/11, Abel Abraham Camarillo Ojeda :
>
>> Obviously, it's not fast...
>
> Well, the problem was exactly speed-related. If not this - I could
> simply dispose of the transaction...
> --
> regards,
> Zbigniew
>
>
It seems like if you switched
On Dec 11, 2012, at 6:26, Zbigniew wrote:
> 2012/12/10, Kevin Grittner :
>
>> Could an option like this be added to the server? Probably. Has
>> anyone worked on such a feature? Not that I know of. Would such a
>> feature be accepted if written? I think a better case would need to
>> be made for
On Dec 11, 2012, at 6:28, Zbigniew wrote:
> 2012/12/11, Tom Lane :
>
>> The complexity and performance costs that people have mentioned are other
>> good reasons not to change it; but even if the change were free on the
>> server side, history says it's not something we ought to mess with.
>
>
On 12/11/2012 08:05 PM, Zbigniew wrote:
> 2012/12/11, Chris Angelico :
>
>> I have considered. It will be beneficial to a small group of users,
>> including yourself
> No, not that small whatsoever; it's easy to find out using Google, how
> many people were looking for some help because of this. Yo
It's faster than restarting the big transaction, maybe...
On Tue, Dec 11, 2012 at 5:48 AM, Zbigniew wrote:
> 2012/12/11, Abel Abraham Camarillo Ojeda :
>
> > Obviously, it's not fast...
>
> Well, the problem was exactly speed-related. If not this - I could
> simply dispose of the transaction...
2012/12/11, Abel Abraham Camarillo Ojeda :
> Obviously, it's not fast...
Well, the problem was exactly speed-related. If not this - I could
simply dispose of the transaction...
--
regards,
Zbigniew
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your s
On Tue, Dec 11, 2012 at 10:36 PM, Zbigniew wrote:
> There are always TWO sides (at least two): creators/designers - and
> the users. Considering how much complexity some kind of modification
> adds to your - programmer's - code, and how it'll make your life more
> difficult, at the same time try t
Obviously, it's not fast...
On Tue, Dec 11, 2012 at 5:42 AM, Abel Abraham Camarillo Ojeda <
acam...@the00z.org> wrote:
> I generally do:
>
> DO $$
> BEGIN
> INSERT INTO ...;
> EXCEPTION
> WHEN UNIQUE_VIOLATION or EXCLUSION_VIOLATION THEN
> NULL; /* ignore this rec
I generally do:
DO $$
BEGIN
INSERT INTO ...;
EXCEPTION
WHEN UNIQUE_VIOLATION or EXCLUSION_VIOLATION THEN
NULL; /* ignore this record */
END;
$$;
On Sun, Dec 9, 2012 at 9:20 PM, Zbigniew wrote:
> Hello,
>
> As I read while googling the web, many people complaine
2012/12/10, Kevin Grittner :
> Could an option like this be added to the server? Probably. Has
> anyone worked on such a feature? Not that I know of. Would such a
> feature be accepted if written? I think a better case would need to
> be made for its value compared to the added code complexity and
Hi,
On 11 December 2012 06:25, Виктор Егоров wrote:
> On the other hand, it is possible to write "whenever sqlerror
> continue;" and this will make ORACLE to process all the statements
> inide the script, ignoring all errors. This is a general feature,
> available not only for sqlplus scripts — a
"Kevin Grittner" writes:
> Zbigniew wrote:
>> No idea, is it simple or very complicated. But if it is simple -
>> why not?
> When I first started using PostgreSQL I was used to a database
> product which would roll back an entire statement on failure, but
> leave the transaction open for another
On Mon, Dec 10, 2012 at 05:02:37PM +0100, Thomas Kellerer wrote:
> Just as a side-note: Oracle also allows you to commit a "transaction" even if
> some of the statements failed
True. I always thought that was a bizarre bug. Certainly, it would
be the day you did
BEGIN;
INSERT INTO sale $bunch
On Mon, Dec 10, 2012 at 06:29:49PM +, Zbigniew wrote:
>
> No, I'm not.
>
> It's able (I mean Postgres) to detect an error, and it's able to react
> on error. "What I'm basically asking for" is an option to change its
> reaction; that's all. Just to change a bit the thing already exisiting
> -
Caveat: I am not a PostgreSQL hacker, and have not looked into its
internals at all, though I've read a number of excellent articles and
blog posts on some of its features (TOAST, HOT updates, MVCC, etc).
I'm a programmer who has made use of PG from a number of languages,
and formed a strong opinio
Zbigniew wrote:
> No idea, is it simple or very complicated. But if it is simple -
> why not?
When I first started using PostgreSQL I was used to a database
product which would roll back an entire statement on failure, but
leave the transaction open for another try. This is handy for
interactive
2012/12/10 Thomas Kellerer
>
> Zbigniew, 10.12.2012 04:20:
>>
>> Yes, I read about using "savepoints" - but I think we agree,
>> it's just cumbersome workaround - and not real solution,
>
>
> It might be a bit cumbersome, but it *is* a proper solution to the problem -
> not a workaround.
Writing
On Mon, Dec 10, 2012 at 11:29 AM, Zbigniew wrote:
> 2012/12/10, Scott Marlowe :
>
>> Databases aren't as simple as you imagine. What you're basically
>> asking for from the pg engine is for it to enclose every insert into a
>> subtransaction (i.e. set a savepoint) to check for an error.
>
> No, I
2012/12/10, Scott Marlowe :
> Databases aren't as simple as you imagine. What you're basically
> asking for from the pg engine is for it to enclose every insert into a
> subtransaction (i.e. set a savepoint) to check for an error.
No, I'm not.
It's able (I mean Postgres) to detect an error, and
On Sun, Dec 9, 2012 at 8:20 PM, Zbigniew wrote:
> Hello,
>
> As I read while googling the web, many people complained about this
> before. Couldn't it be made optional (can be even with "default ON")?
> I understand, that there are situations, when it is a must - for
> example, when the rest of qu
> if { no error during query } {
> do it
> } else {
> withdraw this one
> if { ROLLBACK_ON_ERROR } {
>rollback entire transaction
> }
> }
I fear that this is no-where near as simple as it's been taken for, and
without looking at the code, I would imagine that this would touch so
Chris Angelico, 10.12.2012 16:47:
The other part of the problem is that you're using transactions for
something other than transactional integrity. You're batching up
transactions in order to improve performance. That's certainly
possible, but you're using the database "oddly", so you can't expec
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Zbigniew
> Sent: Monday, December 10, 2012 9:53 AM
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Problem with aborting entire tra
On 12/10/2012 06:52 AM, Zbigniew wrote:
2012/12/10, David Johnston :
I've got a feeling, that all you have to say, is: "if this is the way
it is, it means, that this is good, and shouldn't be changed". You are
unable to explain, why - just the "common belief" etc. is your
rationale (while it
On Tue, Dec 11, 2012 at 1:15 AM, David Johnston wrote:
>> -Original Message-
>> From: Zbigniew [mailto:zbigniew2...@gmail.com]
>> Sent: Monday, December 10, 2012 6:26 AM
>> To: David Johnston
>> Subject: Re: [GENERAL] Problem with aborting entire transactio
Zbigniew, 10.12.2012 04:20:
Yes, I read about using "savepoints" - but I think we agree,
it's just cumbersome workaround - and not real solution,
I disagree.
It might be a bit cumbersome, but it *is* a proper solution to the problem -
not a workaround.
Thomas
--
Sent via pgsql-general
Please reply-to the list, not just myself.
> -Original Message-
> From: Zbigniew [mailto:zbigniew2...@gmail.com]
> Sent: Monday, December 10, 2012 6:26 AM
> To: David Johnston
> Subject: Re: [GENERAL] Problem with aborting entire transactions on error
>
> 2012/
On Dec 9, 2012, at 22:20, Zbigniew wrote:
> Hello,
>
> As I read while googling the web, many people complained about this
> before. Couldn't it be made optional (can be even with "default ON")?
> I understand, that there are situations, when it is a must - for
> example, when the rest of querie
29 matches
Mail list logo
