Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
On 1/2/07, Tom Lane <[EMAIL PROTECTED]> wrote: Lukas Kahwe Smith <[EMAIL PROTECTED]> writes: > Err, I think you misunderstood what I said. My implementation uses > SAVEPOINTs already. The point is having some API where you do not have > to care of you are already in a transaction or not. It's not that hard, is it? if (PQtransactionStatus(conn) == PQTRANS_IDLE) PQexec(conn, "BEGIN"); else PQexec(conn, "SAVEPOINT foo"); regards, tom lane and how the releases and commit will happen? all at once or one by one? -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
On Jan 2, 2007, at 2:01 PM, Lukas Kahwe Smith wrote: Tom Lane wrote: Lukas Kahwe Smith <[EMAIL PROTECTED]> writes: Err, I think you misunderstood what I said. My implementation uses SAVEPOINTs already. The point is having some API where you do not have to care of you are already in a transaction or not. It's not that hard, is it? if (PQtransactionStatus(conn) == PQTRANS_IDLE) PQexec(conn, "BEGIN"); else PQexec(conn, "SAVEPOINT foo"); Its not exactly convenient either, especially in the case of modular code that may be developed by different people. Anyways, like I said I have a solution in my framework to make life of module developers easier. Obviously proper nested transactions would be the ideal, but so it goes. I was just throwing this out here when I saw Peter's comment. +1. Right now it's not as big a deal since we don't allow transaction control inside functions, but if we ever get that ability it will become much more of a pain to write modular code that deals with savepoints/subtransactions. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Tom Lane wrote: Lukas Kahwe Smith <[EMAIL PROTECTED]> writes: Err, I think you misunderstood what I said. My implementation uses SAVEPOINTs already. The point is having some API where you do not have to care of you are already in a transaction or not. It's not that hard, is it? if (PQtransactionStatus(conn) == PQTRANS_IDLE) PQexec(conn, "BEGIN"); else PQexec(conn, "SAVEPOINT foo"); Its not exactly convenient either, especially in the case of modular code that may be developed by different people. Anyways, like I said I have a solution in my framework to make life of module developers easier. Obviously proper nested transactions would be the ideal, but so it goes. I was just throwing this out here when I saw Peter's comment. regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
On 1/2/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: E.g., no GUC parameter. Just change the behavior or don't. Please refer the conversation beginning at: http://archives.postgresql.org/pgsql-hackers/2006-05/msg00249.php That is where this TODO item came from. In the conversation, it was understood that such a change would break many applications, hence one of the option was to introduce a GUC var and keep it on by default, and a couple of releases later, remove the GUC and make the behaviour default ( http://archives.postgresql.org/pgsql-hackers/2006-05/msg00273.php). This would help the programmers can realize that they are doing something wrong, and they can make appropriate changes to their code. The usability of the GUC comes in a production environment, where it is not possible to change the application. The DBA can buy some time by turning the GUC var off. I submitted a patch, which was incorrect and incomplete as I was _very_ new to PGSQL. I could not follow up on it as I was switching jobs at the time. Tom objected to the default=ON setting for the GUC. The TODO has been declared "misconceived", but I guess there's still interest out here. Would like to finish it once we reach a consensus. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes: > Err, I think you misunderstood what I said. My implementation uses > SAVEPOINTs already. The point is having some API where you do not have > to care of you are already in a transaction or not. It's not that hard, is it? if (PQtransactionStatus(conn) == PQTRANS_IDLE) PQexec(conn, "BEGIN"); else PQexec(conn, "SAVEPOINT foo"); regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
On Tue, 2007-01-02 at 11:53 +0100, Peter Eisentraut wrote: > Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian: > > I think you can make the case that this should be an error, or at least > > that's how it got on the TODO list. I can always remove it if people > > don't want the item completed. > > The reason this was added is that modular applications expect that a locally > issued BEGIN ... COMMIT executes a transaction, whereas now you don't know > what you're getting. I think this change would have merit. Interesting point. My only comment is, "Do it one way or the other, don't give me a user or a distribution packager a foot gun." E.g., no GUC parameter. Just change the behavior or don't. Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Alvaro Herrera wrote: news.postgresql.org wrote: While we are on the topic, I have implemented a poor mans nested transaction feature into my database access layer. essentially subsequent calls to begin a transaction after the initial begin simply increase an internal counter and set a savepoint. as you commit the transactions the counter is decreased and the savepoints are released. maybe this could be implemented inside postgresql to make the life of modular programmers easier? Yeah, it's called "SAVEPOINT foo" and "RELEASE foo". Err, I think you misunderstood what I said. My implementation uses SAVEPOINTs already. The point is having some API where you do not have to care of you are already in a transaction or not. Depending on if you are it will either open a new transaction or simply place a savepoint. with the following invented commands: MBEGIN FOO1 // open transaction; set counter to 1 MBEGIN FOO2 // set savepoint FOO2; set counter to 2 MBEGIN FOO3 // set savepoint FOO3; set counter to 3 MROLLBACK FOO3 // rollback to FOO3; set counter to 2 MCOMMIT FOO2 // release FOO2; set counter to 1 MCOMMIT FOO1 // commit regards, Lukas regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
news.postgresql.org wrote: > While we are on the topic, I have implemented a poor mans nested > transaction feature into my database access layer. essentially > subsequent calls to begin a transaction after the initial begin simply > increase an internal counter and set a savepoint. as you commit the > transactions the counter is decreased and the savepoints are released. > maybe this could be implemented inside postgresql to make the life of > modular programmers easier? Yeah, it's called "SAVEPOINT foo" and "RELEASE foo". -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian: I think you can make the case that this should be an error, or at least that's how it got on the TODO list. I can always remove it if people don't want the item completed. The reason this was added is that modular applications expect that a locally issued BEGIN ... COMMIT executes a transaction, whereas now you don't know what you're getting. I think this change would have merit. But how is making BEGIN an error going to improve life for such an application? It'll be just as broken. In fact, if the app depends on getting an error from BEGIN in any critical way, it'll be *more* broken if it's ever run under the default warning-only setting. While we are on the topic, I have implemented a poor mans nested transaction feature into my database access layer. essentially subsequent calls to begin a transaction after the initial begin simply increase an internal counter and set a savepoint. as you commit the transactions the counter is decreased and the savepoints are released. maybe this could be implemented inside postgresql to make the life of modular programmers easier? regards, Lukas ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian: >> I think you can make the case that this should be an error, or at least >> that's how it got on the TODO list. I can always remove it if people >> don't want the item completed. > The reason this was added is that modular applications expect that a locally > issued BEGIN ... COMMIT executes a transaction, whereas now you don't know > what you're getting. I think this change would have merit. But how is making BEGIN an error going to improve life for such an application? It'll be just as broken. In fact, if the app depends on getting an error from BEGIN in any critical way, it'll be *more* broken if it's ever run under the default warning-only setting. 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: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian: > I think you can make the case that this should be an error, or at least > that's how it got on the TODO list. I can always remove it if people > don't want the item completed. The reason this was added is that modular applications expect that a locally issued BEGIN ... COMMIT executes a transaction, whereas now you don't know what you're getting. I think this change would have merit. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Am Donnerstag, 28. Dezember 2006 19:52 schrieb Tom Lane: > Not only is it overzealous, but the proposal to have one reflects a > failure to learn from history. GUC variables that change > transaction-boundary semantics are a bad idea, period: see autocommit. But this option would not, in fact, change the transaction-boundary semantics. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Robert Treat <[EMAIL PROTECTED]> writes: > I thought this was needed for spec compliance? BEGIN isn't in the spec at all ... Now you could point to the spec for START TRANSACTION, which saith 1) If a statement is executed when an SQL-transaction is currently active, then an exception condition is raised: invalid transaction state - active SQL-transaction. However, seeing that the spec doesn't think that an exception necessarily aborts the transaction, I think the case for saying that ERROR is more spec-compliant here than WARNING is mighty thin. And if you want to hold our feet to the fire about whether errors abort transactions or not, this particular point is not one thousandth part of what would need to change. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
On Thursday 28 December 2006 15:44, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote:
> > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > > I would say that a GUC variable for such behavior as listed in the
> > > > TODO is overzealous. We should either enforce it, or not. As we do
> > > > not now, there is no reason imo to change it.
> > >
> > > Not only is it overzealous, but the proposal to have one reflects a
> > > failure to learn from history. GUC variables that change
> > > transaction-boundary semantics are a bad idea, period: see autocommit.
> >
> > Nod. Let's get this TODO removed.
>
> OK, removed.
I thought this was needed for spec compliance? If we have no plans to even
attempt to support it, istm that ought to be noted someplace.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Joshua D. Drake wrote: > On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote: > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > > I would say that a GUC variable for such behavior as listed in the TODO > > > is overzealous. We should either enforce it, or not. As we do not now, > > > there is no reason imo to change it. > > > > Not only is it overzealous, but the proposal to have one reflects a > > failure to learn from history. GUC variables that change > > transaction-boundary semantics are a bad idea, period: see autocommit. > > Nod. Let's get this TODO removed. OK, removed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > I would say that a GUC variable for such behavior as listed in the TODO > > is overzealous. We should either enforce it, or not. As we do not now, > > there is no reason imo to change it. > > Not only is it overzealous, but the proposal to have one reflects a > failure to learn from history. GUC variables that change > transaction-boundary semantics are a bad idea, period: see autocommit. Nod. Let's get this TODO removed. Sincerely, Joshua D. Drake > > regards, tom lane > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > I would say that a GUC variable for such behavior as listed in the TODO > is overzealous. We should either enforce it, or not. As we do not now, > there is no reason imo to change it. Not only is it overzealous, but the proposal to have one reflects a failure to learn from history. GUC variables that change transaction-boundary semantics are a bad idea, period: see autocommit. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
> 1 > (1 row) > > test=> COMMIT; > COMMIT > > I think you can make the case that this should be an error, or at least > that's how it got on the TODO list. I can always remove it if people > don't want the item completed. Well I can tell you that my customers who are postgresql users ;) would howl in fury if we did that. They are already significantly irritated that certain errors are so strict. E.g., postgres=# BEGIN; BEGIN postgres=# ALTER TABLE baz ADD COLUMN bar text; ERROR: relation "baz" does not exist postgres=# SELECT * FROM foo; ERROR: current transaction is aborted, commands ignored until end of transaction block You do not need to argue with me about the purpose :), I understand why it is just really frustrating for many users. I would say that a GUC variable for such behavior as listed in the TODO is overzealous. We should either enforce it, or not. As we do not now, there is no reason imo to change it. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] TODO: Add a GUC to control whether BEGIN inside
Joshua D. Drake wrote: > Hello, > > Is this really a TODO or is this someone being overzealous with the TODO > list? > Add a GUC to control whether BEGIN inside a transcation should abort > the transaction. Well, right now, BEGIN inside a transaction just issues a warning: test=> BEGIN; BEGIN test=> BEGIN; WARNING: there is already a transaction in progress BEGIN test=> SELECT 1; ?column? -- 1 (1 row) test=> COMMIT; COMMIT I think you can make the case that this should be an error, or at least that's how it got on the TODO list. I can always remove it if people don't want the item completed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
