Future development

Hi All,

It's been a while now since we released the 07.03.0260 build of the driver
for evaluation as a possible basis for future versions of psqlODBC. If you
can't remember what I'm talking about, please take a peek at
http://archives.postgresql.org/pgsql-odbc/2006-02/msg00131.p hp

We haven't had any comments either for or against basing future versions of
psqlODBC on this branch despite it being downloaded over 36,000 times(!).
I'd therefore like to ask if anyone has any thoughts either way on the
subject please post to the list so a decision can be made and normal
development can resume!

Regards, Dave.


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Re: Future development

Dave Page writes:

> We haven't had any comments either for or against basing future versions of
> psqlODBC on this branch despite it being downloaded over 36,000 times(!).
> I'd therefore like to ask if anyone has any thoughts either way on the
> subject please post to the list so a decision can be made and normal
> development can resume!

I don't really have an opinion about the methods of implementation,
but I still choose the 7.3 experimental branch for the single reason
that it still has Updatable cursors which I need where I use it.


Tomas

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Future development

=20

> -----Original Message-----
> From: "Tomas Skäre" [mailto:tomas@nocrew.org]=20
> Sent: 17 March 2006 12:26
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Future development
>=20
> Dave Page writes:
>=20
> > We haven't had any comments either for or against basing=20
> future versions of
> > psqlODBC on this branch despite it being downloaded over=20
> 36,000 times(!).
> > I'd therefore like to ask if anyone has any thoughts either=20
> way on the
> > subject please post to the list so a decision can be made and normal
> > development can resume!
>=20
> I don't really have an opinion about the methods of implementation,
> but I still choose the 7.3 experimental branch for the single reason
> that it still has Updatable cursors which I need where I use it.

OK, thanks for the feedback. Anyone else? Luf, Anoop?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Re: Future development

Dave Page wrote:
>>> We haven't had any comments either for or against basing
>> future versions of
>>> psqlODBC on this branch despite it being downloaded over
>> 36,000 times(!).
>>> I'd therefore like to ask if anyone has any thoughts either
>> way on the
>>> subject please post to the list so a decision can be made and normal
>>> development can resume!
>> I don't really have an opinion about the methods of implementation,
>> but I still choose the 7.3 experimental branch for the single reason
>> that it still has Updatable cursors which I need where I use it.
>
> OK, thanks for the feedback. Anyone else?

I for one can't live without the "Level of rollback on errors" feature
of the 7.3 experimental branch. I don't care about which branch is used,
as long as this feature is in there -- the 8.1 branch doesn't work for
me at all. :-/

Cheers,
Bart

---------------------------(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: Future development

Fri, Mar 17, 2006 at 12:40:53PM -0000, Dave Page napsal(a):
> > -----Original Message-----
> > From: "Tomas Skäre" [mailto:tomas@nocrew.org]=20
> >=20
> > Dave Page writes:
> >=20
> > > We haven't had any comments either for or against basing=20
> > > future versions of
> > > psqlODBC on this branch despite it being downloaded over=20
> > > 36,000 times(!).
> > > I'd therefore like to ask if anyone has any thoughts either=20
> > > way on the
> > > subject please post to the list so a decision can be made and norma=
l
> > > development can resume!
> >=20
> > I don't really have an opinion about the methods of implementation,
> > but I still choose the 7.3 experimental branch for the single reason
> > that it still has Updatable cursors which I need where I use it.
>=20
> OK, thanks for the feedback. Anyone else? Luf, Anoop?

I think we may continue in 7.3 branch becouse it is more
powerful version.
I stopped my development becouse I'm not sure if 7.3 branch is ready
for next steps right now. And I don't want spend a lot of time on
8.1 branch.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Future development

> I for one can't live without the "Level of rollback on errors" feature
> of the 7.3 experimental branch. I don't care about which branch is used,
> as long as this feature is in there -- the 8.1 branch doesn't work for
> me at all. :-/

Could you explain me the "Level of rollback on errors"? I think that
when programmer doesn't use autocommit mode he want react on errors
himself.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Future development

Ludek Finstrle wrote:
>> I for one can't live without the "Level of rollback on errors" feature
>> of the 7.3 experimental branch. I don't care about which branch is used,
>> as long as this feature is in there -- the 8.1 branch doesn't work for
>> me at all. :-/
>
> Could you explain me the "Level of rollback on errors"? I think that
> when programmer doesn't use autocommit mode he want react on errors
> himself.

Like I said in my other message, the 8.01 driver doesn't give me a
choice in how to react on errors at all: it forces me to rollback the
complete transaction. I want to have a choice in that. The 7.03 driver
allows me to set the "Level of rollback on errors" to "Statement", which
means that only the failed statement is rolled back, and *I* then have
the choice of whether I want to rollback the remainder of the
transaction as well, or that I want to continue / try something else.

Another example of a situation where the per-statement rollback on
errors is wanted. Situation sketch: we have a client-side object model
with a generic persistence layer that stores the objects in a SQL
database. When we save changes, we try to store all of the objects
WITHOUT deferring constraints, even though there may be circular
references etcetera. The reason for not deferring constraints is that we
want to be able to tell the user which objects are the cause of
constraint violations, something which isn't possible when you simply
get "constraint XXX violated" at commit time. So, what we do is, we try
to store every object, skipping any that fail, then we try the failed
ones again, as long as the set of objects gets smaller. Then only at the
end do we try and defer constraints in order to store the last ones. But
if we can't deliberately try statements, knowing that they might fail
(atomically), this doesn't work. It works on all other databases that we
support, it works on PostgreSQL with the 7.03 driver with "Level of
rollback on errors" set to "Statement", it just doesn't work with the
8.01 driver because it will force us to roll back the transaction.

Cheers,
Bart

---------------------------(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: Future development

Hello

I copy&paste here second thread which is related to this:

> >This is backend related. I assume you use autocommit=off. In this
> >case backend doesn't allow next commands after failed one in
> >one transaction.
>
> I get what autocommit does when I haven't started a transaction, but
> what does "autocommit" mean when I'm inside a manually started transaction?

When you start transaction manually you have to finish it manually.
I see no difference in ending transactions.

> >08.00.0102 driver calls automatic rollback (if I remember it right).
> >Some users voted againist it. And I agreed with them. When programmer
> >manage the transaction he may also manage errors.
>
> Yes. But that also means that he needs to get a choice on whether to
> continue or not. The 8.01 driver forces the programmer to rollback,
> which is not very nice.

You have the choice. You could use savepoints (this is the way used by
7.3 experimental driver). When driver uses savepoints automatically
before each statement it has to be slow down.

> >I see no reason to continue transaction when something in it failed.
> >Transaction may be atomic. All inside is ok or no change happens.
> >It sounds quite odd for me that another RDBMS do it another way.
>
> Well, on other DBMSes the statements themselves seem to act like small
> transactions themselves. If a single statement fails, you can try and
> finish your transaction in another way, or you can roll it back. Your
> choice.

Ok. You're right. I have used too strong words.

Wed, Mar 22, 2006 at 01:38:41PM +0100, Bart Samwel napsal(a):
> Ludek Finstrle wrote:
> >>I for one can't live without the "Level of rollback on errors" feature
> >>of the 7.3 experimental branch. I don't care about which branch is used,
> >>as long as this feature is in there -- the 8.1 branch doesn't work for
> >>me at all. :-/
> >
> >Could you explain me the "Level of rollback on errors"? I think that
> >when programmer doesn't use autocommit mode he want react on errors
> >himself.
>
> Like I said in my other message, the 8.01 driver doesn't give me a
> choice in how to react on errors at all: it forces me to rollback the

It gives you the choice ;-) but not hidden one.

> complete transaction. I want to have a choice in that. The 7.03 driver
> allows me to set the "Level of rollback on errors" to "Statement", which
> means that only the failed statement is rolled back, and *I* then have
> the choice of whether I want to rollback the remainder of the
> transaction as well, or that I want to continue / try something else.

Maybe this could be good for writing DB applications for more RDBMS?

Thanks for disscussion (I hope we will continue). You show me another
point of view.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: Future development

Ludek Finstrle wrote:
> Hello
>
> I copy&paste here second thread which is related to this:
>
>>> This is backend related. I assume you use autocommit=off. In this
>>> case backend doesn't allow next commands after failed one in
>>> one transaction.
>> I get what autocommit does when I haven't started a transaction, but
>> what does "autocommit" mean when I'm inside a manually started transaction?
>
> When you start transaction manually you have to finish it manually.
> I see no difference in ending transactions.

ACK.

>>> 08.00.0102 driver calls automatic rollback (if I remember it right).
>>> Some users voted againist it. And I agreed with them. When programmer
>>> manage the transaction he may also manage errors.
>> Yes. But that also means that he needs to get a choice on whether to
>> continue or not. The 8.01 driver forces the programmer to rollback,
>> which is not very nice.
>
> You have the choice. You could use savepoints (this is the way used by
> 7.3 experimental driver). When driver uses savepoints automatically
> before each statement it has to be slow down.

Of course it will be slightly slower. But I think savepoints are not
that slow, their big cost is at rollback time. At least it's nice to
have it as an option, as in the 7.3 driver.

>>> I see no reason to continue transaction when something in it failed.
>>> Transaction may be atomic. All inside is ok or no change happens.
>>> It sounds quite odd for me that another RDBMS do it another way.
>> Well, on other DBMSes the statements themselves seem to act like small
>> transactions themselves. If a single statement fails, you can try and
>> finish your transaction in another way, or you can roll it back. Your
>> choice.
>
> Ok. You're right. I have used too strong words.

Glad you see things my way. ;-)


> Wed, Mar 22, 2006 at 01:38:41PM +0100, Bart Samwel napsal(a):
>> Ludek Finstrle wrote:
>>>> I for one can't live without the "Level of rollback on errors" feature
>>>> of the 7.3 experimental branch. I don't care about which branch is used,
>>>> as long as this feature is in there -- the 8.1 branch doesn't work for
>>>> me at all. :-/
>>> Could you explain me the "Level of rollback on errors"? I think that
>>> when programmer doesn't use autocommit mode he want react on errors
>>> himself.
>> Like I said in my other message, the 8.01 driver doesn't give me a
>> choice in how to react on errors at all: it forces me to rollback the
>
> It gives you the choice ;-) but not hidden one.

You mean I can set savepoints manually. :-)

>> complete transaction. I want to have a choice in that. The 7.03 driver
>> allows me to set the "Level of rollback on errors" to "Statement", which
>> means that only the failed statement is rolled back, and *I* then have
>> the choice of whether I want to rollback the remainder of the
>> transaction as well, or that I want to continue / try something else.
>
> Maybe this could be good for writing DB applications for more RDBMS?

For portability it would definitely be nice if the driver supports the
other RDBMS drivers' behaviour.

> Thanks for disscussion (I hope we will continue). You show me another
> point of view.

I'll keep an eye on the discussion. Pointing it in the right direction
can save me a whole lot of work later. :-)

--Bart

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Future development

Bart Samwel writes:
> Ludek Finstrle wrote:
>> Could you explain me the "Level of rollback on errors"? I think that
>> when programmer doesn't use autocommit mode he want react on errors
>> himself.

> Like I said in my other message, the 8.01 driver doesn't give me a
> choice in how to react on errors at all: it forces me to rollback the
> complete transaction. I want to have a choice in that. The 7.03 driver
> allows me to set the "Level of rollback on errors" to "Statement", which
> means that only the failed statement is rolled back, and *I* then have
> the choice of whether I want to rollback the remainder of the
> transaction as well, or that I want to continue / try something else.

Really? Considering that there was no backend support at all for such a
thing back in 7.*, this seems improbable.

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: Future development

=20

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org=20
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: 22 March 2006 14:54
> To: Bart Samwel
> Cc: Ludek Finstrle; pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Future development=20
>=20
> Bart Samwel writes:
> > Ludek Finstrle wrote:
> >> Could you explain me the "Level of rollback on errors"? I=20
> think that
> >> when programmer doesn't use autocommit mode he want react on errors
> >> himself.
>=20
> > Like I said in my other message, the 8.01 driver doesn't give me a=20
> > choice in how to react on errors at all: it forces me to=20
> rollback the=20
> > complete transaction. I want to have a choice in that. The=20
> 7.03 driver=20
> > allows me to set the "Level of rollback on errors" to=20
> "Statement", which=20
> > means that only the failed statement is rolled back, and=20
> *I* then have=20
> > the choice of whether I want to rollback the remainder of the=20
> > transaction as well, or that I want to continue / try=20
> something else.
>=20
> Really? Considering that there was no backend support at all=20
> for such a
> thing back in 7.*, this seems improbable.

Not in the backend, but the ODBC REL-07_03_ENHANCED branch has superior
savepoint support over CVS tip.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend