ODBC Developers

Hi All,

As many of you will know, I recently placed a news item on
www.postgresql.org to try to get some new developers working on
psqlODBC. I was pleseantly surprised to find that after just a few days
I had received eight responses from people interested in joining the
project. This message has been BCC'd to them.

First of all, I'd like to say thank you to those that responded - input
from all of you would be most welcome as there are a number of end users
keen to see psqlODBC move forwards. If you have not done so already,
please subscribe to the psql-odbc(at)postgresql(dot)org mailing lists (just
send a message containing the word 'subscribe' (wiithout the quotes) to
psql-odbc-request(at)postgresql(dot)org).

In the remainder of this message, I'll try to outline some history and
what I see as the future for the driver. This is all open for discussion
on-list so feel free to chip in with comments.

History
-------
I first started using psqlODBC back around 1997, when it was maintained
by solely Byron Nikolaidis from Insight Distribution Systems. When Byron
stopped working on the driver, after a period with no maintainer,
Hiroshi Inoue took over, and I started looking after the website and
managing the releases of the driver. It should be noted that whilst I
have done some work on the internals, I am by no means an expert on how
the driver works. After some years, Hiroshi was also forced to quit
working on the driver, thus leaving it in it's current state. At the
same time, my time has also been refocussed elsewhere as I rarely use
the driver nowadays (some of you will know that my primary project,
pgAdmin, now uses libpq), thus I only really have time to chip in now
and again.

The upshot is, that we have a community of users, and a project that
needs to move forwards, but currently isn't.

The future
----------

Over the last few releases, we have been introducing new versions of the
driver, one with ODBC 3 compliance, and one with ODBC 3 compliance, and
Unicode support. We have gradually been promoting the driver to make the
ODBC 3 Unicode driver the default. Changes to CVS have already been
committed to make this the only version of the driver shipped in future
releases, though this has not been tested under *nix at present.

There are a number of tasks that need addressing - following any
discussion, I'd be happy if any of our new volunteers could co-ordinate
efforts to undertake this work. This list is not necessarily complete -
corrections/comments welcome :-)

1) ODBC 3 compliance should be checked. Are all the required ODBC
functions present. Do they work as expected.

2) Ditto, Unicode versions of all the functions.

3) An audit of the code for possible buffer overrun problems should be
undertaken.

4) An update to the v3 fe-be protocol is required.

5) SSL support should be added.

6) The GUI needs a cleanup (move to use of tabs rather than separate
dialogues, and a 'test connection' button?).

7) Documentation and the website needs updating (as always :-) )

(note; would 4 & 5 be better solved by replacing the current code with
libpq?)

In addition, there are always bugs with new versions, and the latest
snapshot is no exception. These need to be fixed as reported.

Initially, any work that is undertaken should be supplied to the list as
patches for review following any appropriate discussion. If the general
concencus is that a patch is good, then I will apply it to CVS. I will
also continue to produce releases for now. In the future, we can look at
giving more people CVS commit privileges once they have proven the
quality of their work (as is the norm for any good open source project).

So, I'll finish up now. I hope I haven't put off any one and welcome any
comments (or a flurry of patches :-) ).

Regards, Dave.

"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> writes:
> As many of you will know, I recently placed a news item on
> www.postgresql.org to try to get some new developers working on
> psqlODBC. I was pleseantly surprised to find that after just a few days
> I had received eight responses from people interested in joining the
> project. This message has been BCC'd to them.

This is really, really good news. With you and Hiroshi both pretty much
withdrawn from development, I was afraid psqlODBC would die on the vine.
(I have no time to contribute to it either :-()

One comment on your todo list:

> 3) An audit of the code for possible buffer overrun problems should be
> undertaken.

I think this is really critical and should be done ASAP. We already
have at least one known issue of this kind. The bad news of course
is that it is boring, tedious work ... but on the other hand it's a
great way to learn one's way around the code. I hope that several of
the new developers will perform such reviews.

regards, tom lane

Dave Page wrote:
> 3) An audit of the code for possible buffer overrun problems should
> be undertaken.

I'm planning to rip out all uses of the libc string functions and
replace them by pqexpbuffer that is also used successfully in libpq.
Look for a patch soon.

> Initially, any work that is undertaken should be supplied to the list
> as patches for review following any appropriate discussion. If the
> general concencus is that a patch is good, then I will apply it to
> CVS.

Maybe you can start by applying the 64-bit fix patch of the other day?

Hi there,

I can tackle 1 and 2. They will also serve as a good introduction to both
ODBC, the driver and unicode.
Where can I get details/specs for all these?

Also another thing that I have come across when using psqlODBC with OTL
(http://otl.sourceforge.net/home.htm) is that the driver
will not work when inserting data with a buffer size other than 1 (this is
the size of the otl_stream buffer).

Regards,
Sterge

-----Original Message-----
From: pgsql-odbc-owner(at)postgresql(dot)org
[mailto:pgsql-odbc-owner(at)postgresql(dot)org]On Behalf Of Dave Page
Sent: Wednesday, June 30, 2004 12:45 PM
To: pgsql-odbc(at)postgresql(dot)org
Subject: [ODBC] ODBC Developers

Hi All,

As many of you will know, I recently placed a news item on
www.postgresql.org to try to get some new developers working on
psqlODBC. I was pleseantly surprised to find that after just a few days
I had received eight responses from people interested in joining the
project. This message has been BCC'd to them.

First of all, I'd like to say thank you to those that responded - input
from all of you would be most welcome as there are a number of end users
keen to see psqlODBC move forwards. If you have not done so already,
please subscribe to the psql-odbc(at)postgresql(dot)org mailing lists (just
send a message containing the word 'subscribe' (wiithout the quotes) to
psql-odbc-request(at)postgresql(dot)org).

In the remainder of this message, I'll try to outline some history and
what I see as the future for the driver. This is all open for discussion
on-list so feel free to chip in with comments.

History
-------
I first started using psqlODBC back around 1997, when it was maintained
by solely Byron Nikolaidis from Insight Distribution Systems. When Byron
stopped working on the driver, after a period with no maintainer,
Hiroshi Inoue took over, and I started looking after the website and
managing the releases of the driver. It should be noted that whilst I
have done some work on the internals, I am by no means an expert on how
the driver works. After some years, Hiroshi was also forced to quit
working on the driver, thus leaving it in it's current state. At the
same time, my time has also been refocussed elsewhere as I rarely use
the driver nowadays (some of you will know that my primary project,
pgAdmin, now uses libpq), thus I only really have time to chip in now
and again.

The upshot is, that we have a community of users, and a project that
needs to move forwards, but currently isn't.

The future
----------

Over the last few releases, we have been introducing new versions of the
driver, one with ODBC 3 compliance, and one with ODBC 3 compliance, and
Unicode support. We have gradually been promoting the driver to make the
ODBC 3 Unicode driver the default. Changes to CVS have already been
committed to make this the only version of the driver shipped in future
releases, though this has not been tested under *nix at present.

There are a number of tasks that need addressing - following any
discussion, I'd be happy if any of our new volunteers could co-ordinate
efforts to undertake this work. This list is not necessarily complete -
corrections/comments welcome :-)

1) ODBC 3 compliance should be checked. Are all the required ODBC
functions present. Do they work as expected.

2) Ditto, Unicode versions of all the functions.

3) An audit of the code for possible buffer overrun problems should be
undertaken.

4) An update to the v3 fe-be protocol is required.

5) SSL support should be added.

6) The GUI needs a cleanup (move to use of tabs rather than separate
dialogues, and a 'test connection' button?).

7) Documentation and the website needs updating (as always :-) )

(note; would 4 & 5 be better solved by replacing the current code with
libpq?)

In addition, there are always bugs with new versions, and the latest
snapshot is no exception. These need to be fixed as reported.

Initially, any work that is undertaken should be supplied to the list as
patches for review following any appropriate discussion. If the general
concencus is that a patch is good, then I will apply it to CVS. I will
also continue to produce releases for now. In the future, we can look at
giving more people CVS commit privileges once they have proven the
quality of their work (as is the norm for any good open source project).

So, I'll finish up now. I hope I haven't put off any one and welcome any
comments (or a flurry of patches :-) ).

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Hi all,

I'm a young developer with some knowledge in various programming languages including C. Nowadays, i'm not capable to contribute to any part of the postgresql project but i want seriously learn what i need in order to contribute.
Can you guys tell me where can i start?
Where can i find usefull information about Databases programming techniques?

Thanx in advance,

Jaime Casanova

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
"Dave Page" writes:
> As many of you will know, I recently placed a news item on
> www.postgresql.org to try to get some new developers working on
> psqlODBC. I was pleseantly surprised to find that after just a few days
> I had received eight responses from people interested in joining the
> project. This message has been BCC'd to them.

This is really, really good news. With you and Hiroshi both pretty much
withdrawn from development, I was afraid psqlODBC would die on the vine.
(I have no time to contribute to it either :-()

One comment on your todo list:

> 3) An audit of the code for possible buffer overrun problems should be
> undertaken.

I think this is really critical and should be done ASAP. We already
have at least one known issue of this kind. The bad news of course
is that it is boring, tedious work ... but on the other hand it's a
great way to learn one's way around the code. I hope that several of
the new developers will perform such reviews.

regards, tom lane

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

http://archives.postgresql.org

---------------------------------
Do You Yahoo!?
Todo lo que quieres saber de Estados Unidos, América Latina y el resto del Mundo.
Visíta Yahoo! Noticias.

I'm not a postgres developer.. and really, all of this information is on the
postgres website.. But I liked reading PostgreSQL by Korry Douglas and Susan
Douglas (ISBN: 0735712573) which gave me all the information I needed about
PostgreSQL itself as well as the various API's. I found them pretty easy to
understand and use. I'm also a C programmer (novice) and the C api (libpq) is
pretty easy to understand if you understand databases.

However, I seem to work better having hard bound copies I can read in meetings
and carry with me. The online documentation is far superior than some of the
competing products, I would certainly start there.

http://www.postgresql.org/docs/7.4/static/libpq.html

-netmask

> Jaime Casanova (systemguards(at)yahoo(dot)com) composed today:

> Hi all,
>
> I'm a young developer with some knowledge in various programming languages including C. Nowadays, i'm not capable to contribute to any part of the postgresql project but i want seriously learn what i need in order to contribute.
> Can you guys tell me where can i start?
> Where can i find usefull information about Databases programming techniques?

On Thursday 01 July 2004 01:10 pm, Jaime Casanova wrote:
>
> I'm a young developer with some knowledge in various programming
> languages including C. Nowadays, i'm not capable to contribute to any
> part of the postgresql project but i want seriously learn what i need in
> order to contribute. Can you guys tell me where can i start?
> Where can i find usefull information about Databases programming
> techniques?
>

First, become intimately familiar with the tool from the user's perspective.
I use PostgreSQL for some major projects, and so I have grown familair with
it. I don't think I could've gotten this familiar without having to
actually use it in a production environment.

Second, start coding extensions to it. I have written C code for both the
client and server side, and have learned tremendously from that.

Finally, start reading code around the parts you are interested in.

I have also found that watching the patches come in will give you a feel for
what is happening. Not only do you see the actual code, but you can watch
the experts talk about it. You can read through the code and then watch as
the server behaves differently. It's pretty amazing.

--
Jonathan Gardner
jgardner(at)jonathangardner(dot)net

Dave Page wrote:
> 4) An update to the v3 fe-be protocol is required.
>
> 5) SSL support should be added.
>
> 6) The GUI needs a cleanup (move to use of tabs rather than separate
> dialogues, and a 'test connection' button?).
>
> 7) Documentation and the website needs updating (as always :-) )
>
> (note; would 4 & 5 be better solved by replacing the current code with
> libpq?)

Using libpq seems like it would be a great solution. Why didn't the
original driver use libpq?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

The developer's FAQ is a good place to start.

---------------------------------------------------------------------------

Jonathan Gardner wrote:
> On Thursday 01 July 2004 01:10 pm, Jaime Casanova wrote:
> >
> > I'm a young developer with some knowledge in various programming
> > languages including C. Nowadays, i'm not capable to contribute to any
> > part of the postgresql project but i want seriously learn what i need in
> > order to contribute. Can you guys tell me where can i start?
> > Where can i find usefull information about Databases programming
> > techniques?
> >
>
> First, become intimately familiar with the tool from the user's perspective.
> I use PostgreSQL for some major projects, and so I have grown familair with
> it. I don't think I could've gotten this familiar without having to
> actually use it in a production environment.
>
> Second, start coding extensions to it. I have written C code for both the
> client and server side, and have learned tremendously from that.
>
> Finally, start reading code around the parts you are interested in.
>
> I have also found that watching the patches come in will give you a feel for
> what is happening. Not only do you see the actual code, but you can watch
> the experts talk about it. You can read through the code and then watch as
> the server behaves differently. It's pretty amazing.
>
> --
> Jonathan Gardner
> jgardner(at)jonathangardner(dot)net
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
>
> !DSPAM:40e4b35d139131332413006!
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Dave Page wrote:
> 1) ODBC 3 compliance should be checked. Are all the required ODBC
> functions present. Do they work as expected.

A brief status on this: We have all ODBC 3 functions in the code, but
the following functions claim various forms of "not (fully)
implemented":

BrowseConnect
ColumnPrivileges
DescribeParam
GetDescRec
SetDescRec

Whether any function works as expected is of course undecidable. :-)

> 2) Ditto, Unicode versions of all the functions.

We have almost all the required Unicode functions, but some functions
are in the file odbcapi25w.c, which is not linked in anywhere. What's
up with that? The function GetDescRecW is completely missing.

The additional required SQL functions are also mostly present, but there
seems to be some duplication/overlap between convert.c and odbc.sql,
that isn't quite clear to me yet.

Overall it looks quite good from the conformance point of view.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/