On Sun, Jun 24, 2012 at 1:37 PM, Rafal Pietrak wrote:
> On Sat, 2012-06-23 at 12:18 +, Jasen Betts wrote:
> > On 2012-06-19, Rafal Pietrak wrote:
> >
> > > And we are talking about interractive psql breaking transaction because
> > > of syntax error - almost always this is a one time typo. I'
On Sat, 2012-06-23 at 12:18 +, Jasen Betts wrote:
> On 2012-06-19, Rafal Pietrak wrote:
>
> > And we are talking about interractive psql breaking transaction because
> > of syntax error - almost always this is a one time typo. I'd prefere it
> > to be a bit more "sloopy", then deployed SQL ap
On 2012-06-19, Rafal Pietrak wrote:
> And we are talking about interractive psql breaking transaction because
> of syntax error - almost always this is a one time typo. I'd prefere it
> to be a bit more "sloopy", then deployed SQL application (e.g.
> non-interactive session).
possibly you could
On Wed, 2012-06-20 at 00:24 -0700, Chris Travers wrote:
> I guess it seems to me that I would not object to a new option for
> transaction behavior where one could do something like SET TRANSACTION
> INTERACTIVE; and have no errors abort the transaction at all (explicit
> commit or rollback require
Em 20/06/2012 11:00, fe...@crowfix.com escreveu:
On Wed, Jun 20, 2012 at 06:36:09AM -0700, fe...@crowfix.com wrote:
On Tue, Jun 19, 2012 at 11:25:24AM -0600, Scott Marlowe wrote:
On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter wrote:
There is also the case of dynamically generated sql statemen
On Wed, Jun 20, 2012 at 06:36:09AM -0700, fe...@crowfix.com wrote:
> On Tue, Jun 19, 2012 at 11:25:24AM -0600, Scott Marlowe wrote:
> > On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter
> > wrote:
> > > There is also the case of dynamically generated sql statements based on
> > > user selection...
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Simon Riggs wrote:
> So it would be useful to have a non-default option of
> statement-level abort for those cases, as an ease of use feature.
I think you misspelled "foot gun"
On Tue, Jun 19, 2012 at 11:25:24AM -0600, Scott Marlowe wrote:
> On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter
> wrote:
> > There is also the case of dynamically generated sql statements based on
> > user selection... being syntax or not, I would never want half job done.
> > Thia is the purpo
On Wed, 2012-06-20 at 00:24 -0700, Chris Travers wrote:
[--]
>
> I guess it seems to me that I would not object to a new option for
> transaction behavior where one could do something like SET TRANSACTION
> INTERACTIVE; and have no errors abort the transaction at all (explicit
> co
On 20/06/2012 08:24, Chris Travers wrote:
> It seems to me there is one very simple reason not to change current
> behavior which those in favor are glossing over.
>
> Most interactions with a database are not occurring over an interface
> like psql with one person typing on one side and the db ex
It seems to me there is one very simple reason not to change current
behavior which those in favor are glossing over.
Most interactions with a database are not occurring over an interface
like psql with one person typing on one side and the db executing on
the other.If that were the case I wou
On 19 June 2012 22:07, Tom Lane wrote:
> Rafal Pietrak writes:
>> The point is, that SQL syntax errors are so obviusly different from
>> execution errors, that noting this distinction should not raise any
>> ambiguity.
>
> I beg to disagree. Typos can manifest themselves as execution errors
> ju
Em 19/06/2012 22:26, Scott Marlowe escreveu:
On Tue, Jun 19, 2012 at 6:19 PM, Edson Richter wrote:
According to documentation,
"TRUNCATE is transaction-safe with respect to the data in the tables: the
truncation will be safely rolled back if the surrounding transaction does
not commit."
You w
On Tue, Jun 19, 2012 at 6:19 PM, Edson Richter wrote:
> According to documentation,
>
> "TRUNCATE is transaction-safe with respect to the data in the tables: the
> truncation will be safely rolled back if the surrounding transaction does
> not commit."
>
> You will find this description at followi
According to documentation,
"TRUNCATEis transaction-safe with respect to the data in the tables: the
truncation will be safely rolled back if the surrounding transaction
does not commit."
You will find this description at following page:
http://www.postgresql.org/docs/9.0/static/sql-truncate
On 20/06/12 01:35, Rafal Pietrak wrote:
On Tue, 2012-06-19 at 19:06 +0800, Craig Ringer wrote:
On 06/19/2012 02:20 PM, Tom Lane wrote:
So you're suggesting that "SELECT 1/0;" should terminate a transaction,
but "SELECT 1//0;" should not? How about "ROLBACK;"? It gets pretty
squishy pretty fa
I like the current behavior. Having been pleasantly surprised that this is how
Pg operates, it is very helpful when I'm working on scripts or batches such as
for creating or populating schemas. If it dies part way through, I know I can
just fix the problem and rerun the whole thing, without ha
But that data was supposed to get transferred into another table
first! Data shouldn't just disappear like that. If you want that kind
of behaviour use a different db that likes to throw your data away
when it shouldn't.
On Tue, Jun 19, 2012 at 1:09 PM, Edson Richter wrote:
> And I will be pleas
On Wed, 2012-06-20 at 08:27 +1200, Gavin Flower wrote:
[]
> > >
> >
> >
> I would be be extremely concerned about any move to allow syntax
> errors not to abort a transaction.
Me too. But it's a nuicence for interractive session when transactions
breakes due to syntax error -
And I will be pleased that data is gone! I really did not expect anything but
this.
If I need such tolerant behavior, then this shall be a feature of my special
app, not a feature of the database... If the developer does not know how to
write sql, then is time to learn. If the problem is the dyn
On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter wrote:
> There is also the case of dynamically generated sql statements based on user
> selection... being syntax or not, I would never want half job done. Thia is
> the purpose of transactions: or all or nothing...
This this this, and again, this.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
...
> ON_ERROR_ROLLBACK=interactive provides a helper for that in psql.
>
> Savepoints are overhead, though, and I don't understand why they're
> required for statements that don't even parse.
Other have handled the latter part of the above al
There is also the case of dynamically generated sql statements based on user
selection... being syntax or not, I would never want half job done. Thia is the
purpose of transactions: or all or nothing...
Tom Lane escreveu:
>Rafal Pietrak writes:
>> The point is, that SQL syntax errors are so o
Hm, sorry but I still can not get into that argument.
Take your example 3 (COMINT in place of COMMIT)
How should the DB know that (and how) to safely recover from such error?
You need to tell - and there are tools to do so right available.
In an interactive session:
- use "autocommit=on" to indi
Rafal Pietrak writes:
> The point is, that SQL syntax errors are so obviusly different from
> execution errors, that noting this distinction should not raise any
> ambiguity.
I beg to disagree. Typos can manifest themselves as execution errors
just as well as syntax errors.
You are probably thi
On Tue, Jun 19, 2012 at 03:35:19PM +0200, Rafal Pietrak wrote:
>
> The point is, that SQL syntax errors are so obviusly different from
> execution errors, that noting this distinction should not raise any
> ambiguity.
Good. One looks forward to your fully-worked-out AI/ESP patch that gets
this r
On Tue, 2012-06-19 at 19:06 +0800, Craig Ringer wrote:
> On 06/19/2012 02:20 PM, Tom Lane wrote:
> > So you're suggesting that "SELECT 1/0;" should terminate a transaction,
> > but "SELECT 1//0;" should not? How about "ROLBACK;"? It gets pretty
> > squishy pretty fast when you try to decide which
On 06/19/2012 02:20 PM, Tom Lane wrote:
So you're suggesting that "SELECT 1/0;" should terminate a transaction,
but "SELECT 1//0;" should not? How about "ROLBACK;"? It gets pretty
squishy pretty fast when you try to decide which sorts of errors are
more important than others.
When put that way
On Tue, Jun 19, 2012 at 02:20:57AM -0400, Tom Lane wrote:
> Craig Ringer writes:
> > I've been working in psql a lot recently, and have started to wonder why
> > statements with syntax errors or other problems that render them
> > unexecutable terminate the transaction.
>
> Well, the obvious re
Craig Ringer writes:
> I've been working in psql a lot recently, and have started to wonder why
> statements with syntax errors or other problems that render them
> unexecutable terminate the transaction.
Well, the obvious reason is that it's hard to tell what the user meant,
so bailing is the
Hi all
I've been working in psql a lot recently, and have started to wonder why
statements with syntax errors or other problems that render them
unexecutable terminate the transaction.
I understand why statements that raise errors during their execution
terminate a transaction, and that expl
31 matches
Mail list logo
