Thread: Res: .NET driver

Hi all!

I know this is OT, sorry for that.

I just wanted you to know that I've read this thread and welcome any and all help in order to get Npgsql in best shape
aspossible. 

As pointed out by Robert, join us on Npgsql Forums so we can discuss. This would be very nice!

I also agree with Brar Piening about the need to have better interfaces and Npgsql Team hopes to get Npgsql in a great
standardso it is easier for .net developers out there to start using Postgresql and enjoy working with Npgsql and
Postgresql!:) That's what I want to happen. 

Andrei, it would be very nice if you could join us to help make Npgsql better!

Thanks in advance.

--
Regards,
Francisco Figueiredo Jr.
http://fxjr.blogspot.com
Npgsql Lead Developer
http://npgsql.projects.postgresql.org
Mono Project Contributor
http://www.go-mono.com
MonoBrasil Project Founder Member
http://monobrasil.softwarelivre.org
--------- Would you tell me, please, which way I ought to go from here?- That depends a good deal on where you want to
getto.        -- Lewis Carroll "Alice's Adventures in Wonderland" 

----- Mensagem original ----
De: Robert Treat <xzilla@users.sourceforge.net>
Para: pgsql-hackers@postgresql.org
Cc: Andrei Kovalevski <andyk@commandprompt.com>
Enviadas: Quinta-feira, 2 de Agosto de 2007 12:49:56
Assunto: Re: [HACKERS] .NET driver

On Thursday 02 August 2007 08:57, Andrei Kovalevski wrote:
> Merlin Moncure wrote:
> > On 8/2/07, Hannu Krosing <hannu@skype.net> wrote:
> >> Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:
> >>> I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
> >>> As stated on NPGSQL page, it doesn't seem to provide seamless
> >>> integration and performance with .NET. Instead when I used ODBC, the
> >>> performance was comparatively better. What's the reason? When can we
> >>> expect .NET driver that provides seamless integration.
> >>
> >> What kind of "seamless integration" are you looking for ?
> >
> > The .net data provider is not as good when working with typed datasets
> > in terms of support from the ide.  Normally for other providers the
> > IDE does everything for you, writing update statements and  such in a
> > ORM fashion.   This is kind of a pain for some of the report designers
> > and other things that want to work with a typed set.  It's possible to
> > work around this, it's just a pain, and changes with each release of
> > visual studio.  Also, the connection pooling portions are buggy
> > (google LOG: incomplete startup packet).
> >
> > The ODBC driver works pretty good actually.  I can't speak about the
> > performance though.
> >
> > merlin
>
>     I have an experience with writing ODBC driver for PostgreSQL
> (https://projects.commandprompt.com/public/odbcng/). I would be happy to
> help community to improve .NET data provider.
>

That would be nice. Of course none of this seems relevant to hackers, so I'd
ask those interested to check out the .net project page at
http://pgfoundry.org/projects/npgsql/

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
               http://www.postgresql.org/about/donate





     Alertas do Yahoo! Mail em seu celular. Saiba mais em http://br.mobile.yahoo.com/mailalertas/

Hi.

Yeah, We have released Ver2.0 now. However, It is MS-VisualStudio and
somewhat difficult. Then, Some change of ADO2.0(.NET2.0)...
we want to clear a problem. However, It seems that very much time is
required one by one. There is many expectations. :-)

Regards,
Hiroshi Saito

> ----- Original Message ----- 
> From: "Francisco Figueiredo Jr." <fxjrlists@yahoo.com.br>
> Hi all!
>
> I know this is OT, sorry for that.
>
> I just wanted you to know that I've read this thread and welcome any and all help in order to get
> Npgsql in best shape as possible.
>
> As pointed out by Robert, join us on Npgsql Forums so we can discuss. This would be very nice!
>
> I also agree with Brar Piening about the need to have better interfaces and Npgsql Team hopes to 
> get
> Npgsql in a great standard so it is easier for .net developers out there to start using Postgresql
> and enjoy working with Npgsql and Postgresql! :) That's what I want to happen.
>
> Andrei, it would be very nice if you could join us to help make Npgsql better!
>
> Thanks in advance.

PostgreSQL has the oldest community of coders, and PostgreSQL itself is the oldest product. Still its performance (in some areas) and GUI does not match MySQL. MySQL .NET Driver gives very good performance for the MySQL Database, FireBird .NET Driver gives performance for FireBird.

Not only it is with .NET Driver, but other areas like pgAdmin for Windows. It is not easy for a beginner to work with. Compare it with MySQL administrator.

Rohit Khare wrote:
> PostgreSQL has the oldest community of coders, and PostgreSQL itself is 
> the oldest product. Still its performance (in some areas) and GUI does 
> not match MySQL. MySQL .NET Driver gives very good performance for the 
> MySQL Database, FireBird .NET Driver gives performance for FireBird.
> 
> Not only it is with .NET Driver, but other areas like pgAdmin for 
> Windows. It is not easy for a beginner to work with. Compare it with 
> MySQL administrator.

I regularly get emails telling me how *good* pgAdmin is compared to our 
competition, and rarely, if ever, the reverse. What do you believe makes 
it hard to use?

Regards, Dave

Seeing the history of PostgreSQL development, following features are expected in pgAdmin:

(1) Facility to insert a column in between other columns during table design.
(2) Facility to view relationship diagram.
(3) Facility to view table performance level graphically.
(4) More documented interface. Example: while creating columns, few boxes are disabled. There is no information on-screen on how to enable them.
(5) Facility to print table details (Name,DataType,Size,Constraint etc.)
(6) Database Statistics (health, index details, log monitoring, Enable/Disable Backup/Recovery Options, Fine Tuning etc.)

Considering a mature RDBMS like PostgreSQL, an intuitive GUI Control Panel is a must.

Regards,
Rohit.

Rohit Khare wrote:
> Seeing the history of PostgreSQL development, following features are 
> expected in pgAdmin:
>
> (1) Facility to insert a column in between other columns during table 
> design.
> (2) Facility to view relationship diagram.
> (3) Facility to view table performance level graphically.
> (4) More documented interface. Example: while creating columns, few 
> boxes are disabled. There is no information on-screen on how to enable 
> them.
> (5) Facility to print table details (Name,DataType,Size,Constraint etc.)
> (6) Database Statistics (health, index details, log monitoring, 
> Enable/Disable Backup/Recovery Options, Fine Tuning etc.)
>
> Considering a mature RDBMS like PostgreSQL, an intuitive GUI Control 
> Panel is a must.
>

So what are *you* doing about it? This is open source, where if you want 
it and it's not there you make it. Otherwise you're just one more 
whinger wanting something for nothing.

cheers

andrew

Rohit Khare wrote:
> Seeing the history of PostgreSQL development, following features are
> expected in pgAdmin:
> 
> (1) Facility to insert a column in between other columns during table
> design.

This I can see how people like, actually. Theorists claim it's not
needed since column order really doesn't matter, but during development
things will just "look nicer". So I can agree with this.


> (2) Facility to view relationship diagram.

I believe this is actually being worked on as a google summer of code
project. So hopefully we'll have that soon.

> (3) Facility to view table performance level graphically.

I think this is also being worked on, at least it's being thought about.

> (4) More documented interface. Example: while creating columns, few
> boxes are disabled. There is no information on-screen on how to enable them.

Want to contribute? ;-)


> (5) Facility to print table details (Name,DataType,Size,Constraint etc.)

You can do much of this already using the reporting feature, no? If you
need further reports, just specifying *exactly* what information you'd
need in the reports would certainly help the hackers to get started.


> (6) Database Statistics (health, index details, log monitoring,
> Enable/Disable Backup/Recovery Options, Fine Tuning etc.)

Much of this *is* available, assuming you have enabled it at the server
level. Perhaps it just needs to be presented differently?


> Considering a mature RDBMS like PostgreSQL, an intuitive GUI Control
> Panel is a must.

I couldn't agree more.

That said, it's probably a good idea to discuss the specifics on the
pgadmin list instead of the backend hackers. Please subscribe there if
you are willing to contribute to the project (with code, documentation,
or just discussing the best ways to do things)

//Magnus

On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
> So what are *you* doing about it? This is open source, where if you want 
> it and it's not there you make it. Otherwise you're just one more 
> whinger wanting something for nothing.

I don't agree with this attitude at all: we should be listening to our
users, not insulting them for their feedback. We can (and should) ignore
certain suggested features, but the idea that asking for a feature is
"whinging" if it doesn't include a patch is plainly wrong, IMHO.

-Neil

Neil Conway wrote:
> On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
>   
>> So what are *you* doing about it? This is open source, where if you want 
>> it and it's not there you make it. Otherwise you're just one more 
>> whinger wanting something for nothing.
>>     
>
> I don't agree with this attitude at all: we should be listening to our
> users, not insulting them for their feedback. We can (and should) ignore
> certain suggested features, but the idea that asking for a feature is
> "whinging" if it doesn't include a patch is plainly wrong, IMHO.
>
>
>   

Well, contributions come in many forms, not just patches. Note too that 
almost all the requested features had nothing to do with core postgres, 
which is what this list is about (IIRC the exception was support for 
logical column ordering, which is already on the TODO list).

Perhaps if there had been less "MySQL/Firebird is great and you guys 
suck" about the original post I would have reacted less strongly :-)

cheers

andrew

Comparing with MySQL/FireBird is not to be taken other-wise. Good things need to be taken care of if they can benefit users. Yes, it is open source and one can contribute code. But the level of expertise and skill also matters. PGSQL development community involve experts in the areas of RDBMS, C/C++. Where as most of the users are not experts in C/C++. My personal areas include VB.NET. I don't think VB is suitable for writing the code you people write.

And yes, original post started with pgAdmin. It has nothing to do with PGSQL. I am a newbie and with above posts it became clear to me that pgAdmin and PGSQL differs. I suggested features considering both as a common product.

They are suggested features not a force that you write code for it.

Andrew Dunstan wrote:
>
> Well, contributions come in many forms, not just patches. Note too
> that almost all the requested features had nothing to do with core
> postgres, which is what this list is about
Well, as a driver developer I can tell you that the core teams attitude
toward driver driven requests can get frustrating. It usually boils down
to "that's the way it is, deal with it", often without even giving me
the option to intelligently deal with it.

I haven't been very active lately (and OLE DB has suffered as a result,
to be sure), but there were some areas where it was not a matter of
doing the coding. I offered initial code, and was willing to work on it
to make sure it matures into a full patch, backwards compatible and
without any significant performance costs. It was more a matter of "it
doesn't affect Postgresql's core, so it's not important" attitude that
really makes life difficult for a driver developer.

Drivers are important, guys. There aren't enough people willing to dive
into the mess that is OLE DB/.Net etc as is. Let's try to at least
acknowledge that there is a need.

Shachar

p.s.
If I may remark on someone else's turf. ODBC has a thing called "dynamic
view". As far as database design, it's a horrid mess, but it's in the
specs, and it requires tracking what happens to specific rows of a query
after a transaction has finished. The last time I checked (which was
when Hiroshi was still the ODBC maintainer), ODBC was emulating it
series of queries on the tid and oid of the rows. It was semantically
correct, but required round trip for each row query, as well as not
being able to work on rows returned from views and other non-table sources.

I don't know who took over ODBC, and whether dynamic views were restored
(the driver turned read-only for a while) or how, but if they come
asking for some crazy scheme that includes tracking what happens to the
rows of a query after the transaction in which it happened is over,
please listen to them. It's not their crazyness, it's ODBC's.

On Saturday 04 August 2007 09:45, Magnus Hagander wrote:
> Rohit Khare wrote:
> > Seeing the history of PostgreSQL development, following features are
> > expected in pgAdmin:
> >
> > (1) Facility to insert a column in between other columns during table
> > design.
>
> This I can see how people like, actually. Theorists claim it's not
> needed since column order really doesn't matter, but during development
> things will just "look nicer". So I can agree with this.

We've gotten requests like this at times for phppgadmin, and I think our 
standard mantra has evolved into "re-implementing core database features in 
the gui client tends to cause nasty surprises for our users".  We actually 
have some experience with this, since we used to implement alter table drop 
column before it lived in postgresql, and we often had users complaining of 
the limitations it had and the things that broke when they used it.  

Looking at the OP's problem, the basic idea would be to create a new table and 
then do some renaming hackery, adding the new column while pulling 
information from the old table, but you run into all sorts of problems with 
dependent objects when you do it that way.  *shrug*  Thats not news to people 
who have studied it, thoough most people don't seem to grasp what is going on 
in the system as a whole.   

><snip>
> > Considering a mature RDBMS like PostgreSQL, an intuitive GUI Control
> > Panel is a must.
>
> I couldn't agree more.
>
> That said, it's probably a good idea to discuss the specifics on the
> pgadmin list instead of the backend hackers. Please subscribe there if
> you are willing to contribute to the project (with code, documentation,
> or just discussing the best ways to do things)
>

I'm not sure it is entirely inappropriate to discuss some of these items 
on -hackers, if we're talking about general solutions to admin and/or gui 
interfaceing problems (even the hacky non-core style solutions might be ok if 
they are approach from the idea of being able to solve a problem at the sql 
level)

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:
> On Saturday 04 August 2007 09:45, Magnus Hagander wrote:
>   
>> Rohit Khare wrote:
>>     
>>> Seeing the history of PostgreSQL development, following features are
>>> expected in pgAdmin:
>>>
>>> (1) Facility to insert a column in between other columns during table
>>> design.
>>>       
>> This I can see how people like, actually. Theorists claim it's not
>> needed since column order really doesn't matter, but during development
>> things will just "look nicer". So I can agree with this.
>>     
>
> We've gotten requests like this at times for phppgadmin, and I think our 
> standard mantra has evolved into "re-implementing core database features in 
> the gui client tends to cause nasty surprises for our users".  We actually 
> have some experience with this, since we used to implement alter table drop 
> column before it lived in postgresql, and we often had users complaining of 
> the limitations it had and the things that broke when they used it.  
>
> Looking at the OP's problem, the basic idea would be to create a new table and 
> then do some renaming hackery, adding the new column while pulling 
> information from the old table, but you run into all sorts of problems with 
> dependent objects when you do it that way.  *shrug*  Thats not news to people 
> who have studied it, thoough most people don't seem to grasp what is going on 
> in the system as a whole.   
>
>   

I think everyone agrees that this particular item is indeed something 
that should be done in core, almost everyone agrees that it should be 
done, and almost all of those agree with an implementation suggestion 
put forward by Tom Lane. So what we need is someone to actually do it 
;-) I will be mildly surprised if it's not done for 8.4.

cheers

andrew

On Mon, Aug 06, 2007 at 03:55:14PM -0400, Robert Treat wrote:
> On Saturday 04 August 2007 09:45, Magnus Hagander wrote:
> > Rohit Khare wrote:
> > > Seeing the history of PostgreSQL development, following features are
> > > expected in pgAdmin:
> > >
> > > (1) Facility to insert a column in between other columns during table
> > > design.
> >
> > This I can see how people like, actually. Theorists claim it's not
> > needed since column order really doesn't matter, but during development
> > things will just "look nicer". So I can agree with this.
>
> We've gotten requests like this at times for phppgadmin, and I think our
> standard mantra has evolved into "re-implementing core database features in
> the gui client tends to cause nasty surprises for our users".  We actually
> have some experience with this, since we used to implement alter table drop
> column before it lived in postgresql, and we often had users complaining of
> the limitations it had and the things that broke when they used it.
>
> Looking at the OP's problem, the basic idea would be to create a new table and
> then do some renaming hackery, adding the new column while pulling
> information from the old table, but you run into all sorts of problems with
> dependent objects when you do it that way.  *shrug*  Thats not news to people
> who have studied it, thoough most people don't seem to grasp what is going on
> in the system as a whole.

If someone's going to work on that, I'd much rather see the effort
expended on allowing the database to actually do this natively, since
it's something people have been asking for forever.
--
Decibel!, aka Jim Nasby                        decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)