Res: .NET driver

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

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

------- Original Message -------
From: "Rohit Khare" <rpk.general@gmail.com>
To: "Dave Page" <dpage@postgresql.org>
Sent: 04/08/07, 12:58:25
Subject: Re: [HACKERS] .NET driver

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

I don't see what any of these have to do with PostgreSQL history but...

(1) Facility to insert a column in between other columns during table
design.

PostgreSQL doesn't allow this post-creation, though the new table dialog that's expected in the next dev cycle will allow it pre-creation.

(2) Facility to view relationship diagram.

E-R diagramming is being developed as a Summer of Code project.

(3) Facility to view table performance level graphically.

What does that mean? You can view the table details graphically as part of a query plan, and we're looking at plotting data distribution histograms, but I'm not sure that either can be defined as "performance level"

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

You usually cannot. They will be relevant to older (or newer) versions of the server.

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

We have reports that you can print.

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

Afaics, we have all of those (and have enhanced many for 1.8).

Regards, Dave

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)