Re: Official ODBC announcement

It would be very good, if you could make your living with the ODBC driver.
Just taking charge of fixing bugs is not enough. If you can sell
enhanced versions, you can make bigger improvements and
don't need to worry about money so much. Then the ODBC driver could
stay up to date with newer ODBC standards.

Commercial PostgreSQL users/customers need a good ODBC driver.
They need an ODBC driver with all the features they need.
Some need good performance too.
They need also compliance for new ODBC and SQL standards.
And some new features...

It is very good for commercial PostgreSQL users,
if there are some people, who maintain the ODBC driver commercially.

It gives for the project trust for continuity.

Personally I would like to have a good ODBC driver at home too.
My personal need has been only to experiment with the driver.

I have experimented ODBC performance features.

I am also interested in transaction savepoint support.
I would like to at least have a one-line patch for savepoints,
because it would make savepoints work without open cursors
inside transactions ...

Unfortenately i have no access into books about ODBC standards.
I do know, how they should be implemented to be compatible
with PostgreSQL, but I don't know what kinds of ODBC functions
should be inserted, or what kind of ODBC function mechanism,
like options and what are the standard ODBC error messages would be needed.

If I have time (I have really small amount of time), I might make an
implementation.

Another fix for the current ODBC driver would be to implement proper
charset support for the Linux side: It seems, that the charset changing
support
has been implemented only for Windows.

I have some thoughts about performance enchancements, but I might not
have time to implement them.

Conclusion:

I hope that you make a living with the ODBC driver commercially.
That way the PostgreSQL ODBC driver would evolve to be good enought even
for more demanding ODBC users. If I would make a living with the ODBC
driver, I could implement some of the ideas, but that is not
what I do for living. So I can't implement many of them.

I hope that you can get something like high enough yearly support payments
from very many commercial users to get a steady income.

I have written a bit code for the savepoint support with cursors. Maybe
it will come usable during the summer. I don't try to make it extremely
fast,
it will be unoptimized. I just try to make it featurefull with a very
good structure.
So my benefit will be to strengthen my learning of object oriented C
coding :) .

The object orientation will cause a bit less speed, but the core
savepoint code is
easy to transfer from one ODBC driver into another one.

My personal point is: do good coding, with good enough speed. If you need
more speed, use another algorithm, or try to avoid the processing
alltogether.
This way the object oriented coding is good enough for speed. Another
benefit
about good object oriented coding is, that it is easier to insert a new
working algorithm
without breaking the existing algorithms.

For example, it would be rather easy to abstract out the Windows charset
conversion
functions. After that, it would be easy to insert iconv() support for
the Linux side.
I prefer iconv(), because it is a reentrant function. ANSI C charset
conversion functions
don't seem to be reentrant :( .

Regards,
Marko Ristola

Robert Treat wrote:

>On Thu, 2005-04-28 at 01:09, Joshua D. Drake wrote:
>
>
>>We have customers that don't want to have to make their software GPL
>>compatible. They are willing to pay reasonable fees to not only help us
>>develop a driver for the overall good of the project but also to have
>>certain commercial rights that would not be there if they used the GPL
>>version.
>>
>>
>
>Would they be willing to pay you a reasonable amount for an ODBC driver
>that was bsd licensed? I can't imagine why they wouldn't since this
>would allow them all the commercial rights they need.
>
>
>
>>>What do you see as the business (or community) advantage of this?
>>>
>>>
>>The business advantage is a $ equation that allows someone like
>>Command Prompt to provide continual support for the driver. The ODBC
>>driver (at least for us) doesn't have any secondary revenue streams.
>>Unlike something like plPHP where we can get residual
>>coding dollars from being the definitive experts in plPHP.
>>
>>The ODBC driver is just that, a driver. If it works it doesn't need
>>support except for continued development and bugfixing
>>
>>
>
>And that is your residual income. Every new version of PostgreSQL is
>going to require *some* hacking around the code, and there are bound to
>be some people who would rather pay you (the experts who wrote the code)
>to do this rather than do it on their own.
>.
>
>
>>The community is going to receive a top notch driver, with commercial
>>support behind it that allows the community as a whole to continue to grow.
>>
>>
>>
>
>But you don't have to do these via a dual license scheme. A single
>license scheme where you decide to only fix bugs that you are paid to
>fix has the potential to work. You don't have to spend time on
>maintaining it if you can't make money on it, other people can feel
>comfortable contributing to the code base, and you can still sell
>enhanced commercial versions if you want.
>
>
>Robert Treat
>
>