Next development steps?

Hello,

I study the driver and there are lot of code which doesn't work since
libpq support. (e.g.) There is support for updatable cursor which doesn't
work (if I'm right) because it's using backend_tuples which isn't
supported.

It seems no other (except swamped Dave and Anoop) is supporting ODBC
driver. I propose these steps:

1) clean the code (and UI) with drop all non-trivial features
- these features make the code unreadable and complicated with
no proper behaviour right now
- there is no error report for them since libpq support
(exclude [#1000413] Optimistic lock cannot be used with updateable
cursors - I think updateable cursor doesn't work at all)
2) create better transaction support (see Marco Ristola post)
- http://archives.postgresql.org/pgsql-odbc/2005-03/msg00128.p hp
- http://archives.postgresql.org/pgsql-odbc/2005-03/msg00116.p hp
3) improve libpq support to use PQprepare, bind parameters
4) full support for only_forward read-only cursor
5) create small steps in support dropped things
and so on ...

Can we create a new development branch at least?

What do you think about it?

Luf

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

http://archives.postgresql.org

Re: Next development steps?

Hi Ludek.

> It seems no other (except swamped Dave and Anoop) is supporting ODBC
> driver. I propose these steps:

> Can we create a new development branch at least?
>
> What do you think about it?

You certain meaning right. However, Doing one DEBUG work with a rapid
change of the 8.x present driver requires great time. And there is someone
who is doing the work. But, The version which was working serves as a curio
and it becomes impossible to apply it with current version. In a general case,
it becomes outdated in requiring time. I think that your latest contribution is
very wonderful activity. I appreciate, you are contributing using time on this
driver very much. Anyway, I vote one.

BTW, I wanted the stable version brunch of REL 7_3.....

Regards,
Hiroshi Saito


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

http://archives.postgresql.org

Re: Next development steps?

=20

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org=20
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Ludek Finstrle
> Sent: 14 December 2005 14:39
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] Next development steps?
>=20
> Hello,
>=20
> I study the driver and there are lot of code which doesn't=20
> work since
> libpq support. (e.g.) There is support for updatable cursor=20
> which doesn't
> work (if I'm right) because it's using backend_tuples which isn't
> supported.
>=20
> It seems no other (except swamped Dave and Anoop) is supporting ODBC
> driver. I propose these steps:
>=20
> 1) clean the code (and UI) with drop all non-trivial features
> - these features make the code unreadable and complicated with
> no proper behaviour right now
> - there is no error report for them since libpq support
> (exclude [#1000413] Optimistic lock cannot be used with=20
> updateable
> cursors - I think updateable cursor doesn't work at all)

What features do you have in mind?

> 2) create better transaction support (see Marco Ristola post)
> - http://archives.postgresql.org/pgsql-odbc/2005-03/msg00128.p hp
> - http://archives.postgresql.org/pgsql-odbc/2005-03/msg00116.p hp

OK.

> 3) improve libpq support to use PQprepare, bind parameters

Yes. Actually I wonder why we don't get rid of the server side prepare
option and always do that (using PQprepare).

> 4) full support for only_forward read-only cursor

OK.

> 5) create small steps in support dropped things
> and so on ...
>=20
> Can we create a new development branch at least?

I'm more inclined to create a stable branch and develop in tip.

Can I also assume you expect to be around for a good while to work on
this ambitious plan? ODBC developers are few and far between, so
starting a major project can be quite a commitment for all of us.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Next development steps?

> > 1) clean the code (and UI) with drop all non-trivial features
> > - these features make the code unreadable and complicated with
> > no proper behaviour right now
> > - there is no error report for them since libpq support
> > (exclude [#1000413] Optimistic lock cannot be used with
> > updateable
> > cursors - I think updateable cursor doesn't work at all)
>
> What features do you have in mind?

All which use backend_tuples or is unreachable at least.
I'm sorry I don't have a list. It is only my ideas based on
what I see through patching. I also try to start cleaning code
and I always stop becouse I go to updateable cursor implementation
or DRIVER_CURSOR or something similar.

> I'm more inclined to create a stable branch and develop in tip.

I'm sorry I'm unable to translate "develop in tip".
I think that we use current stable version as start point for
development branch. I don't think we could share code between this
two branches. It doesn't lead to better (readable) code.

> Can I also assume you expect to be around for a good while to work on
> this ambitious plan? ODBC developers are few and far between, so
> starting a major project can be quite a commitment for all of us.

Yes. I'm planning this mainly for me (maybe someone join me/us).

Regards,

Luf

---------------------------(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: Next development steps?

I believe I can find some time to hang around here.

Regards,
Siva Kumar.K

-----Original Message-----
From: Ludek Finstrle [mailto:luf@pzkagis.cz]
Sent: Wednesday, December 14, 2005 10:34 PM
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Next development steps?

> > 1) clean the code (and UI) with drop all non-trivial features
> > - these features make the code unreadable and complicated with
> > no proper behaviour right now
> > - there is no error report for them since libpq support
> > (exclude [#1000413] Optimistic lock cannot be used with
> > updateable
> > cursors - I think updateable cursor doesn't work at all)
>
> What features do you have in mind?

All which use backend_tuples or is unreachable at least.
I'm sorry I don't have a list. It is only my ideas based on
what I see through patching. I also try to start cleaning code
and I always stop becouse I go to updateable cursor implementation
or DRIVER_CURSOR or something similar.

> I'm more inclined to create a stable branch and develop in tip.

I'm sorry I'm unable to translate "develop in tip".
I think that we use current stable version as start point for
development branch. I don't think we could share code between this
two branches. It doesn't lead to better (readable) code.

> Can I also assume you expect to be around for a good while to work on
> this ambitious plan? ODBC developers are few and far between, so
> starting a major project can be quite a commitment for all of us.

Yes. I'm planning this mainly for me (maybe someone join me/us).

Regards,

Luf

---------------------------(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



**********************************************************

The information contained in, or attached to, this e-mail, contains confidential information and is intended solely for the use of the individual or entity to whom they are addressed and is subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email

************************************************************

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Next development steps?

=20

> -----Original Message-----
> From: Sivakumar K [mailto:sivakumark@aztec.soft.net]=20
> Sent: 14 December 2005 17:12
> To: Ludek Finstrle; Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] Next development steps?
>=20
>=20
> I believe I can find some time to hang around here.
>=20

Great, thanks - will be useful to have you around :-)

BTW, have you moved from Pervasive?

(Luf; Sivakumar worked with Anoop on the libpq conversion).

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Next development steps?

>
> Yes. I'm planning this mainly for me (maybe someone join me/us).
>
> Regards,
>
> Luf
>

Although i'm not an expert C programmer (and i have a lot to
understand about the ODBC API) maybe i can help at least as bug
hunter...

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

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

Re: Next development steps?

-----Original Message-----
From: "Jaime Casanova"
Sent: 14/12/05 17:24:17
To: "Ludek Finstrle"
Cc: "Dave Page", "pgsql-odbc@postgresql.org" l-odbc@postgresql.org>
Subject: Re: [ODBC] Next development steps?

> Although i'm not an expert C programmer (and i have a lot to
> understand about the ODBC API) maybe i can help at least as bug
> hunter...

Certainly - without bug reports we have nothing to fix :-)

Regards, Dave

-----Unmodified Original Message-----
>
> Yes. I'm planning this mainly for me (maybe someone join me/us).
>
> Regards,
>
> Luf
>

Although i'm not an expert C programmer (and i have a lot to
understand about the ODBC API) maybe i can help at least as bug
hunter...

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

---------------------------(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: Next development steps?

Hi Dave,

We have not moved from Pervasive :-)

I was watching the activities going on in the list (Could not get into
much because was very busy) and Ludek indeed deserves an applause for
his active presence in the list.

In my opinion, we should look for the possibility of reworking the
CC_mapping function (which maps PGresult class to QResultClass) to
increase the performance. As Ludek pointed out, we must identify the
code to be cleaned up in different parts of the driver.=20

Dave, can you add Siva also to the developer list? I think he deserves
it because of his great contributions to the development of the libpq
version of psqlodbc, and the further enhancements.=20

Regards,
Anoop


> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-
> owner@postgresql.org] On Behalf Of Dave Page
> Sent: Wednesday, December 14, 2005 10:54 PM
> To: Sivakumar K; Ludek Finstrle
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Next development steps?
>=20
>=20
>=20
> > -----Original Message-----
> > From: Sivakumar K [mailto:sivakumark@aztec.soft.net]
> > Sent: 14 December 2005 17:12
> > To: Ludek Finstrle; Dave Page
> > Cc: pgsql-odbc@postgresql.org
> > Subject: RE: [ODBC] Next development steps?
> >
> >
> > I believe I can find some time to hang around here.
> >
>=20
> Great, thanks - will be useful to have you around :-)
>=20
> BTW, have you moved from Pervasive?
>=20
> (Luf; Sivakumar worked with Anoop on the libpq conversion).
>=20
> Regards, Dave
>=20
> ---------------------------(end of
broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

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

http://archives.postgresql.org

Re: Next development steps?

=20

> -----Original Message-----
> From: Anoop Kumar [mailto:anoopk@pervasive-postgres.com]=20
> Sent: 15 December 2005 05:29
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org; Sivakumar K; Ludek Finstrle
> Subject: RE: [ODBC] Next development steps?
>=20
> Hi Dave,
>=20
> We have not moved from Pervasive :-)

:-). Just wondered as Siva's email address is different from what I
remember.

> I was watching the activities going on in the list (Could not get into
> much because was very busy) and Ludek indeed deserves an applause for
> his active presence in the list.

Absolutely - he seems to have been working tirelessly, and has certainly
jumped straight into some quite complex bugs.

> In my opinion, we should look for the possibility of reworking the
> CC_mapping function (which maps PGresult class to QResultClass) to
> increase the performance. As Ludek pointed out, we must identify the
> code to be cleaned up in different parts of the driver.=20

Yes, I'd was thinking about this whilst driving home last night. It
seems to me that we should be able to make the PGresult a member of the
QResultClass, and then just modify the accessors appropriately. Of
course, it's not quite that simple, but I think it's doable.

> Dave, can you add Siva also to the developer list? I think he deserves
> it because of his great contributions to the development of the libpq
> version of psqlodbc, and the further enhancements.=20

Certainly - what's his pgfoundry username?

Regards, Dave.

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

Re: Next development steps?

=20

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]=20
> Sent: 14 December 2005 17:04
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Next development steps?
>=20
> > > 1) clean the code (and UI) with drop all non-trivial features
> > > - these features make the code unreadable and complicated with
> > > no proper behaviour right now
> > > - there is no error report for them since libpq support
> > > (exclude [#1000413] Optimistic lock cannot be used with=20
> > > updateable
> > > cursors - I think updateable cursor doesn't work at all)
> >=20
> > What features do you have in mind?
>=20
> All which use backend_tuples or is unreachable at least.
> I'm sorry I don't have a list. It is only my ideas based on
> what I see through patching. I also try to start cleaning code
> and I always stop becouse I go to updateable cursor implementation
> or DRIVER_CURSOR or something similar.
>=20
> > I'm more inclined to create a stable branch and develop in tip.
>=20
> I'm sorry I'm unable to translate "develop in tip".

Tip == Head (or trunk in subversion). We put all the new code in
head/tip, and keep the stable code in a separate branch.

> I think that we use current stable version as start point for
> development branch. I don't think we could share code between this
> two branches. It doesn't lead to better (readable) code.

I think that should be assessed on a per-patch basis. If there is a bug
that can be fixed in the stable branch with low risk of causing other
problems, then it should be fixed. If it's specific to the new code, or
high risk, then it should only be fixed in head.

> > Can I also assume you expect to be around for a good while=20
> to work on
> > this ambitious plan? ODBC developers are few and far between, so
> > starting a major project can be quite a commitment for all of us.
>=20
> Yes. I'm planning this mainly for me (maybe someone join me/us).

Well, it seems that the Pervasive guys are back again, and we've had
offers to help with bug hunting :-)

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: Next development steps?

On Wed, Dec 14, 2005 at 04:41:57PM -0000, Dave Page wrote:
> > Can we create a new development branch at least?
>
> I'm more inclined to create a stable branch and develop in tip.

Having suffered through doing development in a branch before; trust me,
you want to do development in HEAD and not in a branch. Doing it in a
branch is an outstanding way to turn things into a real mess...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(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: Next development steps?

> > In my opinion, we should look for the possibility of reworking the
> > CC_mapping function (which maps PGresult class to QResultClass) to
> > increase the performance. As Ludek pointed out, we must identify the
> > code to be cleaned up in different parts of the driver.
>
> Yes, I'd was thinking about this whilst driving home last night. It
> seems to me that we should be able to make the PGresult a member of the
> QResultClass, and then just modify the accessors appropriately. Of
> course, it's not quite that simple, but I think it's doable.

Yes, I was thinking about this. And it need some brainstorm ...
When you use declare/fetch there can be more PGresults or
what about type conversion (you can take data number of time) and so on.

But I'm unable to orient in code becouse a lot of them is unusable
(I think PQprepare, PQexec with binding params can reduce the code a lot).

I call for cleaning the code (even at the expense of some feture lost)
at first.

Luf

---------------------------(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: Next development steps?

=20

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]=20
> Sent: 16 December 2005 12:51
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Next development steps?
>=20
> > > In my opinion, we should look for the possibility of reworking the
> > > CC_mapping function (which maps PGresult class to QResultClass) to
> > > increase the performance. As Ludek pointed out, we must=20
> identify the
> > > code to be cleaned up in different parts of the driver.=20
> >=20
> > Yes, I'd was thinking about this whilst driving home last night. It
> > seems to me that we should be able to make the PGresult a=20
> member of the
> > QResultClass, and then just modify the accessors appropriately. Of
> > course, it's not quite that simple, but I think it's doable.
>=20
> Yes, I was thinking about this. And it need some brainstorm ...
> When you use declare/fetch there can be more PGresults or
> what about type conversion (you can take data number of time)=20
> and so on.

Yep, both valid points.

> But I'm unable to orient in code becouse a lot of them is unusable
> (I think PQprepare, PQexec with binding params can reduce the=20
> code a lot).

OK.

> I call for cleaning the code (even at the expense of some feture lost)
> at first.

I'm not against the idea in principle, but I think we need to discuss
each feature proposed for removal beforehand.

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: Next development steps?

> > I think that we use current stable version as start point for
> > development branch. I don't think we could share code between this
> > two branches. It doesn't lead to better (readable) code.
>
> I think that should be assessed on a per-patch basis. If there is a bug
> that can be fixed in the stable branch with low risk of causing other
> problems, then it should be fixed. If it's specific to the new code, or
> high risk, then it should only be fixed in head.

You're right of course. But if everything goes as I expect then
the development version is much different from stable ...
I don't wait all of you agree so I tried small steps ;-)

> > Yes. I'm planning this mainly for me (maybe someone join me/us).
>
> Well, it seems that the Pervasive guys are back again, and we've had
> offers to help with bug hunting :-)

Nice to hear. It's better than I expect.
For Jaime Casanova: bug hunting is needed as Dave wrote. I think over
psqlODBC (regression) test suite in addition. I hope it isn't so hard
(but time consuming).

You complimented me and I have to cut down the time for psqlodbc
development during Xmas becouse I have to reinstall, upgrade and feature
grow the server and all clients workstations till people go back to work
at 3. January 2006. I hope I find one or two hours per two or three days.
I expect I'll be at work for 12 hours (or even more) per day ...

Regards,

Luf

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

http://archives.postgresql.org

Re: Next development steps?

> > I call for cleaning the code (even at the expense of some feture lost)
> > at first.
>
> I'm not against the idea in principle, but I think we need to discuss
> each feature proposed for removal beforehand.

I take a look at cleaning backend_tuples (as it isn't used) and I see
I'll remove this features (not working now):

- updateable cursor
- driver cursor implementation (keysets)
- we support only forward only cursor and static cursor after cleaning
- the support for other cursor kinds is broken now

I see nothing more but I don't go throught this cleaning yet becouse
I don't want to do needless work.

Do you agree with removing this features?

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Next development steps?

On 20/12/05 7:45 pm, "Ludek Finstrle" wrote:

>>> I call for cleaning the code (even at the expense of some feture lost)
>>> at first.
>>
>> I'm not against the idea in principle, but I think we need to discuss
>> each feature proposed for removal beforehand.
>
> I take a look at cleaning backend_tuples (as it isn't used) and I see
> I'll remove this features (not working now):
>
> - updateable cursor

Hmm, that is the last major feature that Hiroshi was working on before he
had to move on. How broken is it in reality? I'm loathe to remove it if it's
just the few remaining issues that he would have probably fixed in a fairly
short time anyway.

> - driver cursor implementation (keysets)
> - we support only forward only cursor and static cursor after cleaning
> - the support for other cursor kinds is broken now

OK.

> I see nothing more but I don't go throught this cleaning yet becouse
> I don't want to do needless work.

Of course. Another one to consider is whether or not there is anything to
gain from client side prepare. The eventual aim is to use Pqprepare and
PQexecPrepared of course, but I wonder if there is any short term gain in
simplicity to be had by removing the client side code sooner rather than
later.

Regards, Dave



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

Re: Next development steps?

> > I take a look at cleaning backend_tuples (as it isn't used) and I see
> > I'll remove this features (not working now):
> >
> > - updateable cursor
>
> Hmm, that is the last major feature that Hiroshi was working on before he
> had to move on. How broken is it in reality?

If I understand it well this depends on driver cursor implementation
(keysets). The libpq changes broke it. It use backend_tuples which
isn't supported now at all. I don't know how much is it broken.

This is reason why I call for branching. We keep it in stable branch.
We simplify the development code and when we want implement this
feature back we have stable branch from which we can study Hiroshi
implementation.

> > I see nothing more but I don't go throught this cleaning yet becouse
> > I don't want to do needless work.
>
> Of course. Another one to consider is whether or not there is anything to
> gain from client side prepare. The eventual aim is to use Pqprepare and
> PQexecPrepared of course, but I wonder if there is any short term gain in
> simplicity to be had by removing the client side code sooner rather than
> later.

I don't want replay problems from libpq implementation. Libpq changes
broke cursor implementations. Cursors (keyset, updateable) doesn't
work since this changes. What's the problem with removing it from
development code? There is no bug report (as I know instead of your
own - from 7 November).

The problem is we're changing core without knowledge of higher level
(change PQexec ... without knowledge how cursors depends on it ...).

It'll be easier and quicker to implement PQprepare, better transaction
support, internal unicode support, etc when the code is clean. There
is a lot of code which isn't reachable now.
Why we take a care on broken code in development?

Regards,

Luf

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

http://archives.postgresql.org

Re: Next development steps?

On 21/12/05 10:04 am, "Ludek Finstrle" wrote:

>>> I take a look at cleaning backend_tuples (as it isn't used) and I see
>>> I'll remove this features (not working now):
>>>
>>> - updateable cursor
>>
>> Hmm, that is the last major feature that Hiroshi was working on before he
>> had to move on. How broken is it in reality?
>
> If I understand it well this depends on driver cursor implementation
> (keysets). The libpq changes broke it. It use backend_tuples which
> isn't supported now at all. I don't know how much is it broken.
>
> This is reason why I call for branching. We keep it in stable branch.
> We simplify the development code and when we want implement this
> feature back we have stable branch from which we can study Hiroshi
> implementation.

OK - I just want to be sure we're not causing more work than is necessary.

>>> I see nothing more but I don't go throught this cleaning yet becouse
>>> I don't want to do needless work.
>>
>> Of course. Another one to consider is whether or not there is anything to
>> gain from client side prepare. The eventual aim is to use Pqprepare and
>> PQexecPrepared of course, but I wonder if there is any short term gain in
>> simplicity to be had by removing the client side code sooner rather than
>> later.
>
> I don't want replay problems from libpq implementation. Libpq changes
> broke cursor implementations. Cursors (keyset, updateable) doesn't
> work since this changes. What's the problem with removing it from
> development code? There is no bug report (as I know instead of your
> own - from 7 November).

I logged the bug after getting multiple reports from end users.

> The problem is we're changing core without knowledge of higher level
> (change PQexec ... without knowledge how cursors depends on it ...).
>
> It'll be easier and quicker to implement PQprepare, better transaction
> support, internal unicode support, etc when the code is clean. There
> is a lot of code which isn't reachable now.
> Why we take a care on broken code in development?

No reason at all - like I said, I just want to be sure that removing it now,
then re-implementing it will definitely be less work than fixing it in
place.

OK, so to get things moving, I think we should look to release a stable
version (08.01.0200) as soon as possible, and then branch a stable version
from that. Are there any outstanding issues to resolve/commit before we can
think about doing that? The only one I can think of is Tom's 64bit concerns
which I really think we need to fix first, but requires a suitable machine
to properly test on of course.

Regards, Dave



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Next development steps?

> OK, so to get things moving, I think we should look to release a stable
> version (08.01.0200) as soon as possible, and then branch a stable version
> from that. Are there any outstanding issues to resolve/commit before we can
> think about doing that? The only one I can think of is Tom's 64bit concerns
> which I really think we need to fix first, but requires a suitable machine
> to properly test on of course.

I don't think release have to wait for this one.

There are known bugs:
- report for sqlstate (1000495) - I try to solve it now.
+ 1 waiting
- SEGFAULT during SQLCancel (1000475)
+ 0 waiting
- private announce about problems with Text larger than X bytes
+ 1 waiting

I don't know what all you want to give into new release.

There is also two cleanup patches after psqlodbc-8.01.0105 which isn't
tested by users. I think we can't apply these cleanup patches to
stable version. It show us a little bit more backend_tuples behaviour.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Next development steps?

=20

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]=20
> Sent: 21 December 2005 11:53
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Next development steps?
>=20
> > OK, so to get things moving, I think we should look to=20
> release a stable
> > version (08.01.0200) as soon as possible, and then branch a=20
> stable version
> > from that. Are there any outstanding issues to=20
> resolve/commit before we can
> > think about doing that? The only one I can think of is=20
> Tom's 64bit concerns
> > which I really think we need to fix first, but requires a=20
> suitable machine
> > to properly test on of course.
>=20
> I don't think release have to wait for this one.

I do, because Tom will be needing a good release for inclusion in FC5,
otherwise it may end up being rolled back to an 07.xx release if he
thinks the problem is too risky to release (which it sounds like he
does).

> There are known bugs:
> - report for sqlstate (1000495) - I try to solve it now.
> + 1 waiting
> - SEGFAULT during SQLCancel (1000475)
> + 0 waiting
> - private announce about problems with Text larger than X bytes
> + 1 waiting

OK.

> I don't know what all you want to give into new release.

Not sure what you mean?
=20
> There is also two cleanup patches after psqlodbc-8.01.0105 which isn't
> tested by users. I think we can't apply these cleanup patches to
> stable version. It show us a little bit more backend_tuples behaviour.

OK, I'm not worried about cleanups as long as it is as bug-free as
possible.

Regards, Dave

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

Re: Next development steps?

> > I don't think release have to wait for this one.
>
> I do, because Tom will be needing a good release for inclusion in FC5,
> otherwise it may end up being rolled back to an 07.xx release if he
> thinks the problem is too risky to release (which it sounds like he
> does).

Ok. I didn't know this informations. But I can try it in January at first.
What's the deadline?

> > There are known bugs:
> > - report for sqlstate (1000495) - I try to solve it now.
> > + 1 waiting

Solved (I hope).

> > - SEGFAULT during SQLCancel (1000475)
> > + 0 waiting
> > - private announce about problems with Text larger than X bytes
> > + 1 waiting

I hope I'll solve it before the end of week.

> > I don't know what all you want to give into new release.
>
> Not sure what you mean?

It looks to me that psqlodbc-08.01.0105 with bug 1000475 solved is
the most stable since libpq conversion.
I don't use cleanups as I wrote before.

But the most features has 07.03.255 from Hiroshi Saito.
When we create new stable branch why don't create one for 07.03?

> OK, I'm not worried about cleanups as long as it is as bug-free as
> possible.

I don't worry about bugs but about losing next steps to updateable cursor.

Regards,

Luf

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

Re: Next development steps?

On 21/12/05 1:39 pm, "Ludek Finstrle" wrote:

>>> I don't think release have to wait for this one.
>>
>> I do, because Tom will be needing a good release for inclusion in FC5,
>> otherwise it may end up being rolled back to an 07.xx release if he
>> thinks the problem is too risky to release (which it sounds like he
>> does).
>
> Ok. I didn't know this informations. But I can try it in January at first.
> What's the deadline?

Don't know. Last time we spoke there had been some delays, but that was a
while back. I'm assuming you need this fixed for FC5 Tom - what's the
current deadline?

> It looks to me that psqlodbc-08.01.0105 with bug 1000475 solved is
> the most stable since libpq conversion.

It's certainly looking that way, thanks to you.

> But the most features has 07.03.255 from Hiroshi Saito.
> When we create new stable branch why don't create one for 07.03?

And do what with it? It's code that has deviated significantly from the main
tree, has never been released by us, and is as far as I'm aware, largely
untested, certainly by the general community. In addition, the architecture
is basically that which we're in the middle of ripping out and rewriting.

>> OK, I'm not worried about cleanups as long as it is as bug-free as
>> possible.
>
> I don't worry about bugs but about losing next steps to updateable cursor.

I mean the stable release - that should be as bug free as possible.

Regards, Dave



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

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

Re: Next development steps?

Dave Page writes:
> Don't know. Last time we spoke there had been some delays, but that was a
> while back. I'm assuming you need this fixed for FC5 Tom - what's the
> current deadline?

The next FC5 deadline is test2 freeze on 9 Jan. So if you make a
release in the next week or two, I can sneak it into that. If not,
there's still some margin for error, because there will be a test3 a
month later, and updates that are just bug fixes should still be
fair game at that point.

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: Next development steps?

=20

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
> Sent: 21 December 2005 15:25
> To: Dave Page
> Cc: Ludek Finstrle; pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Next development steps?=20
>=20
> Dave Page writes:
> > Don't know. Last time we spoke there had been some delays,=20
> but that was a
> > while back. I'm assuming you need this fixed for FC5 Tom -=20
> what's the
> > current deadline?=20
>=20
> The next FC5 deadline is test2 freeze on 9 Jan. So if you make a
> release in the next week or two, I can sneak it into that. If not,
> there's still some margin for error, because there will be a test3 a
> month later, and updates that are just bug fixes should still be
> fair game at that point.

OK, thanks Tom.

Regards, Dave.

---------------------------(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