Search Postgresql Archives

Re: Problem with aborting entire transactions on error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-
> owner@xxxxxxxxxxxxxx] On Behalf Of Zbigniew
> Sent: Monday, December 10, 2012 9:53 AM
> To: pgsql-general@xxxxxxxxxxxxxx
> Subject: Re:  Problem with aborting entire transactions on error
> 
> 2012/12/10, David Johnston <polobo@xxxxxxxxx>:
> 
> > Please reply-to the list, not just myself.
> 
> Sorry.
> 
> > If it requires coding something to provide the user the desired
> > flexibility then whether or not such flexibility is wise or unwise is
> > going to go into said decision.
> 
> So?
> 
> > Also, since you are begging others to solve your own problems
> 
> Now, not just a problem of mine - but of many others as well, as I wrote.
And
> I was "begging" already: "please, read carefully" (I meant:
> with understanding).
> 
> > you are in many ways behaving as a child.
> 
> When someone doesn't design his/her clothes on his own, doesn't sew
> boots, bake bread etc. - "behaves like a child"?

You are taking the analogy to an absurd extreme.  That said, you are not
generally asking Nike or the local baker to customize their recipes and then
give you the end result for free.

> 
> >  Especially with an Open
> > Source project like PostgreSQL adults are welcomed and encouraged to
> > solve their own problems by altering the source code and, in the
> > spirit of community, contributing it back to the project (contribution
> > also means you do not have to maintain your own custom version of the
> software).
> 
> If I knew the "innards" of Postgres as good, as its present developers
> - maybe I could alter the code. But since I don't know them - I'm
perfectly
> sure, that the ones, who created the code, are able to introduce such
> improvement during about 1/20 of the time, I had to spend trying to do it
by
> myself.
> 
> > Please do not take this as a personal affront;
> 
> Yes, I took this as personal affront, because IT IS a personal affront. Do
you
> really think, that your "please, do not take" is changing this?

I can hope.  Given that e-mail is a text-only medium it makes since to at
least attempt to put some comments into a proper context explicitly since
body language and tone-of-voice cannot be used to convey such.

> 
> > It is easy to complain but apparently no one feels strongly enough to
> > either code a solution themselves or sponsor someone else to do so.
> 
> From what I see, the development is going on - then my conclusion is, that
> there are people "feeling strong enough" - and therefore I wanted to let
> them know, where they got wrong.

You generalize where I am specifically referring to this explicit feature.

> 
> > As I have not
> > seen any core coders respond I cannot be certain whether there are
> > underlying technical issues preventing this but there is at the least
> > a resource allocation concern since neither code donors nor those
> > sponsored by clients have made the time to implement this "simple
> > feature".  It may be more productive, not being a core coder yourself,
> > to simply ask why such a feature has not been implemented given the
> > apparent demand instead of asserting (from ignorance) that such an
> > implementation should be very simple to accomplish.  The later
> > approach (as well as your response to me -
> > personally) is much more confrontational and contrary (the direct
> > reply at
> > least) to the posted etiquette for this community.
> 
> No idea, what made you so upset with this "direct response" - just clicked
> "Reply", and forgot to check the recipient's address.
> Actually, the sender address should be pgsql-general@xxxxxxxxxxxxxx
> already.
> 
> 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's not that
"common"
> at all, as I wrote). You have no arguments against, but: "code it by
yourself",
> "it must be perfect, when it works so", and so on.
> 
> According to you the development can be stopped at this time, since
> everything is perfect.

No.  But everything is the way it is for some reason.  "This would be a
useful feature" and "why do not things work this way" both are excellent
approaches to instigating change and obtaining the understanding as to the
"why" of how things are.  "This is a bug and the solution is simple - though
I have never actually coded the PostgreSQL" is a less effective way of doing
so.

I've already agreed that your idea has merit (maybe not much, but some).
However, since it is not that way currently (and the problem is not a new
one) there likely exists some underlying reason said feature has not been
implemented.  I offer, via induction and some experience, that said feature
is not in high demand, not as simple as you claim, and in many ways is
undesirable - thus no one has taken the time to implement it.  You either
need a more convincing (and novel) argument or you need to contact someone
like PGExperts, 2ndQuadrant, EnterpriseDB (for example and none of whom I am
affiliated with) and pay them to implement the feature for you (likely much
less expensive than learning C and the codebase and doing it yourself).

Given that we are both ignorant on the technical aspects of said feature,
and our conversation is getting too pointed, I suggest that you simply wait
for a response from someone more qualified and in the meantime (since even
if someone coded this feature today it would not be in production release
until 9.3) code your ETL according to the best-practice I suggested earlier.
If the staging table is too large a burden AND no one volunteers to
implement your feature your options have been put before you.

David J.




-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux