Re: [Oledb-dev] A major rewrite of the Postgres OLE DB Provider. - Mailing list pgsql-general

Jeremy Lea wrote:
>  - Runs multiple queries (using PQexec) if you pass a command with no
>    parameters and IID_NULL for the return record set.
>
You should be aware that there is a security advantage to NOT being able
to do that, in fact.

On the plus side, it does allow servers older than 7.4 to work with the
provider, under certain cases. On the don't-care side, so what?
>  - Proper type handling.
>
I'd love an explanation in what, you think, was missing.
>  - Much cleaner code (IMHO), no more STL or exceptions.
>
A matter of taste. I think this design breaks every OOD instruction out
there (read - no switch-case on child classes).
>  - IMultipleRowsets.  libpq can't return multiple results.  What was
>    there was a complete hack.
>
No, it was an interface between provider and server. It was documented,
and was used.
>  - Parsing of parameters on stored procedures.  This was a hack,
Yes, but the hack is in the OLE-DB's specs. Quite a number of programs
don't work without it.
>  which
>    was being done at the wrong place in the code.
>
I'd love it if you elaborated on that.
>  - Support for some types (_text, utinyint, varcharci)
>  - TIMESTAMP WITH TIMEZONE is reported in GMT not local, since there is
>    no OLE DB type for this (so you can't go backwards).
>
If you cannot support data-types that are implemented in PG, and have a
reasonable representation in OLE DB, what makes this type support "proper"?

Also, if I understand my very brief passing over the code correctly, if
I have two coloumns, one of type timestamp and one of type timestamptz,
and I read both in, and then send a parametrized update for both to the
same values I read, one of them will change.
>  - check threading and locking.
>
Unless you switched the provider from "apartment" mode (and I see you
haven't), you don't need to. It will run in a single thread anyways.
> I hope this is useful to someone.  I would welcome any patches to add
> other features.  I'm managing this in a local CVS repository at the
> moment...  Not quite sure what I'm going to do about this and the
> PgFoundry project yet.
>
Then allow me to make a suggestion, if I may.

We're already (and I am, at least to some extent, to blame for the lack
of activity here) in a pretty bad place. Having two forks on a project
that only lists one developer means something has gone very wrong with
the project already. In fact, we now have as many forked versions as we
do developers. If the mailing list was swarming with rejected patches,
I'd understand this situation. As is, I think this was totally uncalled for.

The way to manage open source projects is to "release often, release
early". This gives you early access to feedback (and, at the very worst,
is still not worse off than keeping a local copy). For example, if you
started sending patches when you just started off, I'm sure a more
reasonable discussion of what is the best way for the type system to be
like, thus possibly leading to an implementation that was:
1. Single - i.e. less confusing for the users.
2. Better than either existing implementations.

It's obviously too late for that now. What I suggest is this:
Open a new pgfoundry project for your provider. Please also rename it.
It is confusing enough to have two driver implementations. Having two
driver implementations with the same DLL name is really too much.

I think that it would be best if you did NOT open a new mailing list for
the fork, but used oledb-devel, at least initially. I think that it
would be best, long term, to only have one provider, and a unified list
will help get the community to vote on which one it should be.

Finally, a word of caution. The ATL code is copyrighted by Microsoft.
The license under which they gave you the code (appears as part of
EULA.TXT in Visual Studio 6) is NOT LGPL compatible (nor any other free
license compatible, but you are bound to LGPL by my copyright). This
means, as far as I can tell, that you are not allowed to copy code from
ATL and include it, modified or not, in the provider's code. Had you
send me those pieces of code as patches, they would have been rejected
immediately for that reason alone.

Here is the relevant section from the VS6 EULA (emphasis mine):
> 3.8    Redistributable Code-Visual C++ and Visual Studio: Microsoft
> Foundation Classes (MFC), Template Libraries (ATL), and C runtimes
> (CRTs).  If this EULA accompanies Visual C++ or Visual Studio, then in
> addition to the rights granted in Section 1, Microsoft grants you the
> right to use and modify the source code version of those portions of
> the SOFTWARE PRODUCT that are identified as MFC, ATL, or CRTs
> (collectively, the "VC Redistributables"), for the sole purposes of
> designing, developing, and testing your software product(s). Provided
> you comply with Section 4.1 and you rename any files created by you
> that are included in the Licensed Product (defined below), Microsoft
> grants you a nonexclusive, royalty-free right to reproduce and
> distribute the *object code* version of the VC Redistributables,
> including any modifications you make. For purposes of this section,
> "modifications" shall mean enhancements to the functionality of the VC
> Redistributables.
Admittedly, I sometimes had to squirm quite badly in order to bypass ATL
limitations (and, in one case, outright memory corruption bug) without
copying ATL code into my code and modifying it. My version of the
provider relies entirely on the ATL anyone compiling the provider brings
with his/her own compiler, sometimes to the point of hacking around
stuff, merely because I believe that doing anything else is a copyright
violation. Just a point for you to consider.
> Regards,
>   -Jeremy
>
Shachar