On 31.01.2018 19:58, David G. Johnston wrote:
> Now that I've skimmed the tutorial again I think pointing the reader of
> the SQL Commands there to learn how it works in practice is better than
> trying to explain it in BEGIN and/or SAVEPOINT.
That seems like a good idea, yeah.
> I decided to ad
On Tue, Jan 30, 2018 at 1:40 AM, Robert Zenz
wrote:
> On 30.01.2018 03:07, David G. Johnston wrote:
> > So, my first pass at this.
>
> Nice, thank you.
>
> > + These are of particular use for client software to use when executing
> > + user-supplied SQL statements and want to provide try/catc
On 2018-01-30 08:40:11 +, Robert Zenz wrote:
> On 30.01.2018 03:07, David G. Johnston wrote:
> > So, my first pass at this.
>
> Nice, thank you.
>
> > + These are of particular use for client software to use when executing
> > + user-supplied SQL statements and want to provide try/catch be
On 2018-01-29 06:36:41 -0700, David G. Johnston wrote:
> On Mon, Jan 29, 2018 at 1:37 AM, Robert Zenz
> wrote:
>
> Documentation, bug report, mailing list discussions,
> something like that. In particular I'm interested in the questions:
>
> * Why are they required in combination wi
On Tue, Jan 30, 2018 at 8:25 AM, Rakesh Kumar
wrote:
> >
> > I'm not sure about the terminology here, though, because the Transaction
> > Tutorial (https://www.postgresql.org/docs/9.6/static/tutorial-
> transactions.html)
> > speaks of "aborted" transactions, while you use the term "failed" here.
>
> I'm not sure about the terminology here, though, because the Transaction
> Tutorial
> (https://www.postgresql.org/docs/9.6/static/tutorial-transactions.html)
> speaks of "aborted" transactions, while you use the term "failed" here.
Purely from a user point of view, shouldn't "aborted" mean a
On 30.01.2018 03:07, David G. Johnston wrote:
> So, my first pass at this.
Nice, thank you.
> + These are of particular use for client software to use when executing
> + user-supplied SQL statements and want to provide try/catch behavior
> + where failures are ignored.
Personally, I'd rewor
David G. Johnston wrote:
> > > It may be worth updating the docs here...
> >
> So, my first pass at this. I'm probably going a bit outside what would
> normally be covered in the SQL
> Command section but it does feel right at first blush.
>
> Also attached; not compiled.
>
> As a bug fix I've
On Mon, Jan 29, 2018 at 6:59 AM, Robert Zenz
wrote:
> > It may be worth updating the docs here...
>
> I'd vote for that. I would have expected to see this mentioned in the
> documentation a little bit more prominent than just a single sentence at
> the end
> of the transaction tutorial. A short s
On Mon, Jan 29, 2018 at 9:00 AM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Mon, Jan 29, 2018 at 8:33 AM, Tom Lane wrote:
> >> What we do have though is client-side support for appropriate behaviors.
> >> In psql, see the AUTOCOMMIT and ON_ERROR_ROLLBACK control variables.
>
> > Not q
"David G. Johnston" writes:
> On Mon, Jan 29, 2018 at 8:33 AM, Tom Lane wrote:
>> What we do have though is client-side support for appropriate behaviors.
>> In psql, see the AUTOCOMMIT and ON_ERROR_ROLLBACK control variables.
> Not quite the same. I think what people probably want is for psql
On 29.01.2018 16:33, Tom Lane wrote:
> That behavior does exist, and so does documentation for it; you're just
> looking in the wrong place.
>
> Years ago (7.3 era, around 2002) we experimented with a server-side
> GUC variable "AUTOCOMMIT", which switched from the implicit-commit-
> if-you-don't-
On Mon, Jan 29, 2018 at 8:33 AM, Tom Lane wrote:
> What we do have though is client-side support for appropriate behaviors.
> In psql, see the AUTOCOMMIT and ON_ERROR_ROLLBACK control variables.
> Other interfaces such as JDBC have their own ideas about how this ought
> to work.
>
Not quite the
Robert Zenz writes:
> On 29.01.2018 15:11, Alban Hertroys wrote:
>> If you start a transaction and something goes wrong in the process,
>> the logical behaviour is to fail - the user will want to rollback to a
>> sane state, doing any more work is rather pointless because of that.
>> Allowing a co
On 29.01.2018 15:11, Alban Hertroys wrote:
> IMHO, the burden of explaining that is with those RDBMSes that don't
> behave properly:
>
> If you start a transaction and something goes wrong in the process,
> the logical behaviour is to fail - the user will want to rollback to a
> sane state, doing
On 29 January 2018 at 14:59, Robert Zenz wrote:
> On 29.01.2018 14:36, David G. Johnston wrote:
...
> From my point of view, no, it shouldn't be changed. It has always been this
> way
> and I find nothing wrong with the approach, it is only something that you need
> to be aware of, that's all.
>
On 29.01.2018 14:36, David G. Johnston wrote:
> Those questions would not be answered in user-facing documentation. You
> can explore the git history and search the far-back mailing list archives if
> you wish to satisfy your curiosity. For me this is how it works - the only
> question for me is
On Mon, Jan 29, 2018 at 1:37 AM, Robert Zenz
wrote:
> Documentation, bug report, mailing list discussions,
> something like that. In particular I'm interested in the questions:
>
> * Why are they required in combination with failing statements (when every
> other database does an "automatic save
On 29.01.2018 12:37, Adam Tauno Williams wrote:
> It this statement true? I very much feel *not*. This depends on how
> you have set AUTO_COMMIT - and it certainly is not true for
> transactions of multiple statements.
Maybe I should clarify at that point that AUTO_COMMIT is OFF, and yes, that i
> * Why are they required in combination with failing statements (when
> every other database does an "automatic savepoint and rollback" for a
> failed statement)?
It this statement true? I very much feel *not*. This depends on how
you have set AUTO_COMMIT - and it certainly is not true for
tra
On 26.01.2018 17:11, David G. Johnston wrote:
> The convention for these lists is to inline or bottom-post. Top-posting
> is discouraged.
Okay, I'll keep it in mind.
> Here's my take, the docs support this but maybe take some interpretation...
>
> A SAVEPOINT begins what is effectively a sub-
On Fri, Jan 26, 2018 at 9:47 AM, Melvin Davidson
wrote:
> > ...the presence of a version is bad, only the badgering of people asking
> questions to provide it when it has no bearing on the answer...
>
> Really? Is it that hard for someone to provide version and O/S?
>
Its difficult to remember
> ...the presence of a version is bad, only the badgering of people asking
questions to provide it when it has no bearing on the answer...
Really? Is it that hard for someone to provide version and O/S?
>The timestamp on the email is likely more than sufficient
Do you really think op's look for t
On Fri, Jan 26, 2018 at 9:27 AM, Melvin Davidson
wrote:
> >
>
>> As far as I'm aware neither PostgreSQL nor OS version do matter for this
>
>
> Yes as of this date. However, that is not to say that the SQL standard (or
> PostgreSQL) may change
> in the _future_, such that there "may" be a "ROLLBA
>
> As far as I'm aware neither PostgreSQL nor OS version do matter for this
Yes as of this date. However, that is not to say that the SQL standard (or
PostgreSQL) may change
in the _future_, such that there "may" be a "ROLLBACK TO SAVEPOINT OR
CONTINUE" after a failure,
in which case, someone e
On Fri, Jan 26, 2018 at 8:57 AM, Robert Zenz
wrote:
> In PostgreSQL the use of savepoints is
> required:
>
> start transaction
> insert into A
> create savepoint
> insert into B but fail
> rollback to savepoint
> insert into C
> commit
>
> Otherwise the transaction is,
On Fri, Jan 26, 2018 at 8:42 AM, Melvin Davidson
wrote:
>
> On Fri, Jan 26, 2018 at 10:32 AM, Robert Zenz
> wrote:
>
The convention for these lists is to inline or bottom-post. Top-posting
is discouraged.
> Well, no. What I'm looking for is information on how the transactions
>> behave in
What I'm looking for is more information/documentation on that topic that I can
use as source and link back to (from a blog post).
That last paragraph in your first link is exactly what I meant. Let's start to
clarify things, put into pseudo code:
start transaction
insert into A
inser
On Fri, Jan 26, 2018 at 10:32 AM, Robert Zenz
wrote:
> Well, no. What I'm looking for is information on how the transactions
> behave in
> an error case, and why there is the requirement to have a savepoint in
> place to
> be able to continue a transaction after a failed statement.
>
> As far as
Well, no. What I'm looking for is information on how the transactions behave in
an error case, and why there is the requirement to have a savepoint in place to
be able to continue a transaction after a failed statement.
As far as I'm aware neither PostgreSQL nor OS version do matter for this, I'm
On Fri, Jan 26, 2018 at 9:47 AM, Robert Zenz
wrote:
> I'm currently doing a small writeup of a bug fix in our framework which
> involves
> savepoints in PostgreSQL (JDBC). However, I have a hard time locating the
> documentation regarding this. I mean, from what I can extract from various
> sourc
31 matches
Mail list logo
