Обсуждение: Fetature enhancement request : use of libgda in PostgreSQL to access legacy databases.

Dear all,

libgda (http://www.gnome-db.org) offers a common interface to 
PostgreSQL, MySQL, Oracle, Sybase, ... databases. Libgda is based on Corba 
and gives access to most database and schema objects (tables, columns, views, 
functions are supported, triggers will soon be). It also has XML query 
support, unified types and connexion pooling. 

libgda is an independant library with no dependency to Gnome.

Why not integrate libgda in PostgreSQL to register and access remote database 
objects? This would allow the "attachment" and integration of foreign tables 
& views into PostgreSQL.

Best regards,
Jean-Michel POURE

Dear Jean-Michel,
did you notice http://gasql.sourceforge.net in the applications section
of the gnome-db site? It is supposed to be a PostgreSQL administration
tool, and seems to be nice looking at the screenshots... maybe you
just need to remove GNOME integration...
Just my 2 cents :-)
Best regards,
Andrea Aime

Jean-Michel POURE wrote:
> 
> Dear all,
> 
> libgda (http://www.gnome-db.org) offers a common interface to
> PostgreSQL, MySQL, Oracle, Sybase, ... databases. Libgda is based on Corba
> and gives access to most database and schema objects (tables, columns, views,
> functions are supported, triggers will soon be). It also has XML query
> support, unified types and connexion pooling.
> 
> libgda is an independant library with no dependency to Gnome.
> 
> Why not integrate libgda in PostgreSQL to register and access remote database
> objects? This would allow the "attachment" and integration of foreign tables
> & views into PostgreSQL.
> 
> Best regards,
> Jean-Michel POURE
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

Le Lundi 11 Février 2002 10:12, Andrea Aime a écrit :
> did you notice http://gasql.sourceforge.net in the applications section
> of the gnome-db site? It is supposed to be a PostgreSQL administration
> tool, and seems to be nice looking at the screenshots... maybe you
> just need to remove GNOME integration...
> Just my 2 cents :-)

Dear Andrea,

The purpose of my last mail was to propose the integration a libgda client 
into PostgreSQL. For example, it should be possible to attach an Oracle table 
into PostgreSQL, with the ability to run SELECTs, UPDATEs and maybe JOIN 
queries (???).

This is pure computer-fiction, but MySQL might well provide such feature as 
well and query PostgreSQL objects...

Coming back to gasql, if we happen to port pgAdmin2 
(http://pgadmin.postgresql.org) to Linux, why not use libgda and create a 
multi-vendor GUI directly.

People were discussing lately about adding SQL compatibility layers in 
PostgreSQL (i.e Oracle compatibility). IMHO, this is not the right direction 
to go first because it would demand too much investment.

On the converse, if we integrate libgda BOTH into PostgreSQL AND in a future 
GUI client, we are winning.

Just my 2 cents. My opinion is that the community should concentrate on real 
issues, starting with the most needed ones (ALTER TABLE ALTER COLUMN, CREATE 
OR REPLACE VIEW, CREATE OR REPLACE TRIGGER) and then work on GUI tools and 
abstraction layers to open PostgreSQL to the world.

Just my 2 cents. What do you think my friends?

Cheers,
Jean-Michel POURE

On Mon, 11 Feb 2002, Jean-Michel POURE wrote:

> 
> The purpose of my last mail was to propose the integration a libgda client 
> into PostgreSQL. For example, it should be possible to attach an Oracle table 
> into PostgreSQL, with the ability to run SELECTs, UPDATEs and maybe JOIN 
> queries (???).

It would be inappropriate for PostgreSQL to be made an interface to other
RDBMSs. What would this achieve? Why would it be useful?

> 
> This is pure computer-fiction, but MySQL might well provide such feature as 
> well and query PostgreSQL objects...

If that's what they want to do...

> People were discussing lately about adding SQL compatibility layers in 
> PostgreSQL (i.e Oracle compatibility). IMHO, this is not the right direction 
> to go first because it would demand too much investment.

PostgreSQL does need greater support of SQL99 and some extensions to SQL
found in other proprietary systems, but this is not the right way to go
about doing it. It needs to support them natively so that it can replace
other systems, not work in conjunction with them.


> Just my 2 cents. My opinion is that the community should concentrate on real 
> issues, starting with the most needed ones (ALTER TABLE ALTER COLUMN, CREATE 
> OR REPLACE VIEW, CREATE OR REPLACE TRIGGER) and then work on GUI tools and 
> abstraction layers to open PostgreSQL to the world.

I think you are off the mark here. The addition of trigger and rule/view
recompilation is a convenience at best and there are alternatives to
ALTER TABLE DROP COLUMN. Take a look at the TODO list: the most urgent
items relate to replication/clustering, point-in-time recovery and
row-reuse. All in all, it is these features which are much more desirably
to current and prospective users.

Gavin

Le Lundi 11 Février 2002 12:33, Gavin Sherry a écrit :
> The addition of trigger and rule/view
> recompilation is a convenience at best and there are alternatives to
> ALTER TABLE DROP COLUMN. Take a look at the TODO list: the most urgent
> items relate to replication/clustering, point-in-time recovery and
> row-reuse. All in all, it is these features which are much more desirably
> to current and prospective users.

Many projects ask users to vote for priority features.
Who can speak for end-users? Gavin, we need a pool in the to-do-list ...
These are hackers priorities which ***may** differ from end-user ones.

1) End-user point of view

My humble and personnal opinion, shared by many end-users, is that CREATE
TABLE AS (or whatever based on CREATE TABLE AS and UPDATE FROM) is not a
valid alternative. A database sysadmin with 500 tables, triggers and rules
cannot use alternatives. We need some basic features :
- to modify schema objects (CREATE OR REPLACE VIEW, CREATE OR REPLACE
TRIGGER).
- to drop schema objects (ALTER TABLE DROP COLUMN).

I would be very please if some users could express themselves. What is your
opinion as regards CREATE TABLE AS, ALTER TABLE DROP COLUMN, etc...

What is the end-user priority for such features in 7.3 ?

2) Use of libgda to query legacy databases

Would it be possible to add this feature in the the to-do-list (very low
priority = in the long run):
" use libgda to query legacy databases (Oracle, Sybase, MySQL) transparently
from PostgreSQL in order to access both data (tables, views) and schema
objects (triggers, functions, rules, types, etc..)".

Is this computer fiction to attach Oracle tables in PostgreSQL using libgda?
I can't tell and I would be happy to know the hackers' opinion.

Best regards,
Jean-Michel POURE

Le Lundi 11 Février 2002 16:52, Andrew Sullivan a écrit :
> If it's that important to you, implement it yourself, or pay one
> of the able developers to work on a feature you want.

Thanks for the information. If you help us, I pay you a beer in Paris. Dave
Page will probably too in Oxford, so that makes two beers. Dave Page is
working hard on pgAdmin2 writing thousands lines of code. As for myself, I
will concentrate on something comparable to pgAdmin2 in a libgda / GTK+
environment because I think Windows has no future.

CREATE OR REPLACE VIEW / TRIGGER and ALTER TABLE DROP COLUMN are real
priorities for us at pgAdmin team (http://pgadmin.postgresql.org). I don't
know PostgreSQL internals, but it should take a few days/weeks to an
experienced hacker to add these features.

So why should I do it myself ? We are a community after all. We are not
working for money but helping each others. If we are bringing pgAdmin to a
large audience, we need more help from hackers on what we consider important :

>>>>
It should be possible to modify or drop any schema object (with a priority on
views, triggers and columns). This is absolute priority for us. Can anyone
help us? Can we make sure it will be added to 7.3? Thanks in advance.
>>>>

Cheers,
Jean-Michel POURE

Jean-Michel POURE wrote:
>
> CREATE OR REPLACE VIEW / TRIGGER and ALTER TABLE DROP COLUMN are real
> priorities for us at pgAdmin team (http://pgadmin.postgresql.org). I don't
> know PostgreSQL internals, but it should take a few days/weeks to an
> experienced hacker to add these features.

Jean-Michel,

    I think you underestimate the problem a little.

    Doing  CREATE OR REPLACE is not that trivial as you appear to
    think.  The existing PL handlers (for PL/Tcl and PL/pgSQL  at
    least)   identify   functions  by  their  pg_proc  OID.   The
    functions body text is parsed only on the first call to  that
    function during the entire session. So changing the functions
    prosrc attribute after having called it already wouldn't take
    effect until the next "session". But changing the OID as well
    corrupts existing SPI plans in other functions plus rules.

    Now it might be possible to tell  your  function  handler  to
    recompile that function at the next call without changing the
    OID, but how do you tell the function  handlers  in  all  the
    other  concurrently running backends to do so after finishing
    their current transaction?

    The reason for this feature not beeing implemented yet is not
    "that just noone is in the mood for".  It is that the general
    multiuser support structures aren't in  place  and  a  little
    local sandbox-hack just wouldn't cut it.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Jan Wieck <janwieck@yahoo.com> writes:
>     Now it might be possible to tell  your  function  handler  to
>     recompile that function at the next call without changing the
>     OID, but how do you tell the function  handlers  in  all  the
>     other  concurrently running backends to do so after finishing
>     their current transaction?

This is in fact all dealt with for CREATE OR REPLACE FUNCTION, but
Jan's point holds also for CREATE OR REPLACE other-stuff.  The syntax
change alone is the least of one's worries when implementing such
things.

We were foolish enough to accept a patch for CREATE OR REPLACE FUNCTION
that did not deal with propagating the changes, and had to do a lot of
work to clean up after it.  We will not be so forgiving next time...

            regards, tom lane

Le Lundi 11 Février 2002 20:35, Jan Wieck a écrit :
>     Now it might be possible to tell  your  function  handler  to
>     recompile that function at the next call without changing the
>     OID, but how do you tell the function  handlers  in  all  the
>     other  concurrently running backends to do so after finishing
>     their current transaction?
>
>     The reason for this feature not beeing implemented yet is not
>     "that just noone is in the mood for".  It is that the general
>     multiuser support structures aren't in  place  and  a  little
>     local sandbox-hack just wouldn't cut it.

Thank you for the explaination. I feel stupid. Please, don't flame me for
this now :

Could PostgreSQL be working in two modes : development (SET DEVELOPMENT MODE)
and production (SET PRODUCTION MODE).

1) In development mode, each object has an md5 signature showing whether the
object is updated or not. If the object has changed, it is reloaded. This
would work even in a cluster. Object modification and deletion would only be
allowed in development mode.

2) In production, object deletion and modification would not be possible. No
need for md5 signatures then.

Switching from production <-> development would only be possible after all
transactions have ended. Pretty stupid, I agree, but this would make life
easier. Just my 0,00002 cents.

Cheers,
Jean-Michel

> CREATE OR REPLACE VIEW / TRIGGER and ALTER TABLE DROP COLUMN are real
> priorities for us at pgAdmin team
> (http://pgadmin.postgresql.org). I don't
> know PostgreSQL internals, but it should take a few days/weeks to an
> experienced hacker to add these features.

I can see the utility of CREATE OR REPLACE VIEW, however for me the DROP
COLUMN is way more useful.  I can't begin to express how annoying it is to
not be able to drop a column.  Sooo annoying...

> So why should I do it myself ? We are a community after all. We are not
> working for money but helping each others. If we are bringing
> pgAdmin to a
> large audience, we need more help from hackers on what we
> consider important :

To a certain extent I agree.  I have definitely seen times where I have
spent hours and hours and hours of coding doing something that a core
developer can do in no time, but just isn't inclined to do.

As an aside: did anyone read my post about SET NOT NULL?  I am happy to
implement this for 7.3, but no-one answered my questions about if it's in
the parser or not, and where to put the code?

> It should be possible to modify or drop any schema object (with a
> priority on
> views, triggers and columns). This is absolute priority for us.
> Can anyone
> help us? Can we make sure it will be added to 7.3? Thanks in advance.

The other side of this is that you are using a completely free product coded
by volunteers.  There's no way you can make sure it will be added - all you
can do is to try to convince a developer to implement it.  Again, if I sat
down for a week of coding, I might be able to do it, but someone more
familiar with postgres can probably do it in a day...

Chris

Le Mardi 12 Février 2002 07:29, Christopher Kings-Lynne a écrit :
> I can see the utility of CREATE OR REPLACE VIEW, however for me the DROP
> COLUMN is way more useful.  I can't begin to express how annoying it is to
> not be able to drop a column.  Sooo annoying...

I recieved a mail from Neil Conway. Here it is :

If ALTER TABLE DROP COLUMN is important to you guys, why not use the
existing code for it? Define _DROP_COLUMN_HACK__ and re-compile, it
should work.  I think the implementation is pretty messy: you, or
someone from your time, is welcome to improve it, or suggest a better
way to do things.  This code is also experimental, so it could
definately do with some testing and QA.

My point is that, for this feature at least, there are certainly things
that you guys can do to increase the likelihood of ALTER TABLE DROP
COLUMN being in the 7.3 release.

Cheers,
Neil Conway

On Tue, Feb 12, 2002 at 09:57:48AM +0100, Jean-Michel POURE wrote:
> Le Mardi 12 Février 2002 07:29, Christopher Kings-Lynne a écrit :
> > I can see the utility of CREATE OR REPLACE VIEW, however for me the DROP
> > COLUMN is way more useful.  I can't begin to express how annoying it is to
> > not be able to drop a column.  Sooo annoying...
>
> I recieved a mail from Neil Conway. Here it is :
>
> If ALTER TABLE DROP COLUMN is important to you guys, why not use the
> existing code for it? Define _DROP_COLUMN_HACK__ and re-compile, it
> should work.  I think the implementation is pretty messy: you, or
> someone from your time, is welcome to improve it, or suggest a better
> way to do things.  This code is also experimental, so it could
> definately do with some testing and QA.

LOL! For ages I have been thinking that this is the obvious way of solving
this problem, wondering why no-one had done it yet. Well, obviously someone
did it and pointed out the flaws at the same time. In fact, it's even cooler
now with lazy vacuum, as it could clean out the column in the background,
replacing any values with NULL which, IIRC, don't take any space on disk,
just a bit in a bitmap.

For anyone wanting to know more about this, see the doc/TODO.detail/drop in
the source tree.

> My point is that, for this feature at least, there are certainly things
> that you guys can do to increase the likelihood of ALTER TABLE DROP
> COLUMN being in the 7.3 release.

It's certainly a nice feature, but I'm not dying for it. There are other
features I want first :).

--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
> Terrorists can only take my life. Only my government can take my freedom.

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> To a certain extent I agree.  I have definitely seen times where I have
> spent hours and hours and hours of coding doing something that a core
> developer can do in no time, but just isn't inclined to do.

Well, you know, there is some method in our madness.  We'd like to see
more people develop the skills to work on Postgres, and the above is how
you do it.  (How do you think the core developers learned?)  If we did
all the "easy" stuff because it was easy, there'd be no appropriate
projects for new developers to tackle.

Which is not to say that DROP COLUMN is easy; it's not.

            regards, tom lane

I'm new to the list but I'm going to speak up anyways.  Being a core 
developer on several other projects, I feel that it's important to point 
out that both comments are valid here.  As a core developer, I certainly 
don't want to implement seemingly lessor features when more pressing 
issues are at hand.  At the same time, I would like to see user demand 
met and have some of the other developers lend a hand while polishing 
their knowledge on the project in general.  What I've found especially 
useful has been to tutor and guide (okay, hand-hold) newer/younger 
developers to my projects so that their abilities are quickly 
complimented.  I find that using IRC or even other IM technology can go 
a long way toward providing support for would-be developers.  Especially 
for projects of this complexity.  I find that this helps well beyond 
that of a mailing list as people tend to be more timid in a public 
forum.  After all, it's well understood that a degree of p2p interaction 
is often very helpful and tends to be even more so as the complexity of 
the topic grows.

Tutoring can not only allow developers that are less intimate with the 
code become more useful but help ensure the effort they put forward is 
not only accepted but implemented in an ideal manner.  This is a win for 
the developers and the project as a whole.  I find it also helps build a 
level of trust with future submissions from the developer in question. 
Of course, it also helps build retention with newer developers as it 
more quickly allows them to feel like they are making a difference.  A 
key ingredient for any developer that is to stay with any project for 
the long haul.

In fact, I'm happy this came up as I recently emailed a core developer 
asking for places to start as well as any preferred documentation to 
start with.  Basically I was told read the code and go read the docs. 
Which is exactly where I was before I emailed him.  This is not to say 
that I wasn't happy to have him reply but his response pretty much 
provided no value and added nothing beyond what common sense tells you.  Wouldn't it be more helpful to point would-be
developersat a specific 
 
section of code telling them why they'd want to start there and where 
any specific documentation is that may be of value?

Now, I'm not saying we should move away from the mailing list, rather, 
I'm saying that the core developers way want to reconsider how some 
requests for help are answered and maybe even consider other forms of 
complimentary communication.  Doesn't a hour of a core developers time 
in trade for multiple increase in productivity of another developer seem 
like a good trade?

Just some food for thought.

Greg



Tom Lane wrote:
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> 
>>To a certain extent I agree.  I have definitely seen times where I have
>>spent hours and hours and hours of coding doing something that a core
>>developer can do in no time, but just isn't inclined to do.
>>
> 
> Well, you know, there is some method in our madness.  We'd like to see
> more people develop the skills to work on Postgres, and the above is how
> you do it.  (How do you think the core developers learned?)  If we did
> all the "easy" stuff because it was easy, there'd be no appropriate
> projects for new developers to tackle.
> 
> Which is not to say that DROP COLUMN is easy; it's not.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

[2002-02-12 09:54] Greg Copeland said:

Please understand that I am a wannabe-developer at the bottom of
a big learning curve when reading my comments.

| I'm new to the list but I'm going to speak up anyways.  Being a core 
| developer on several other projects, I feel that it's important to point 
| out that both comments are valid here.  As a core developer, I certainly 
| don't want to implement seemingly lessor features when more pressing 
| issues are at hand.  At the same time, I would like to see user demand 
| met and have some of the other developers lend a hand while polishing 
| their knowledge on the project in general.  

I think the problem is the perception of "lesser" features.  What
an outsider may see as a little problem, may infact be a large 
problem that cannot be suitably solved at the present time, or 
require other seemingly-unrelated infrastructure to accomplish.
_Much_ of what some core developers work on is totally orthogonal
to anything I'd be able to work on right now.

| What I've found especially 
| useful has been to tutor and guide (okay, hand-hold) newer/younger 
| developers to my projects so that their abilities are quickly 
| complimented.

I can assure you that if you show that you are putting forth effort,
there will be a developer who can and will help you when you need it.
This means you _will_ spend 10 times as long on a problem than the
developer who's helping.  This is the way it should be.  The biggest
hurdle to postgres development is the size/complexity of the code,
and there is only one way to overcome that; dedication, time and
expertise -- things that all of the core developers have invested
and earned.

| I find that using IRC or even other IM technology can go 
| a long way toward providing support for would-be developers.  Especially 
| for projects of this complexity.  

I agree that it seems like it would be nice to get a quick answer 
for a 'simple' problem, but you miss out on all the non-answers,
which increase familiarity with the codebase.  I do appreciate
being pointed in the right direction when I'm wandering around
the wrong area, and I think that is about all that should be done.

| I find that this helps well beyond 
| that of a mailing list as people tend to be more timid in a public 
| forum.

All I can suggest is to suck up the timidity.  I know I've made a
monkey of myself on a few occasions, and I'm sure I will again until
I learn what I need.  This is part of the learning process.  Also, 
hiding valuable communication on private channels does nothing to 
inform new would-be-developers of past questions/problems; not using
the email archives when in 'idea' mode is a sure sign that the
would-be-developer needs to learn to use those archives -- a sin
I've been guilty of :-(

| After all, it's well understood that a degree of p2p interaction 
| is often very helpful and tends to be even more so as the complexity of 
| the topic grows.

I agree that a public, archived, irc might be useful, but you have 
to take into consideration the fact that, at least for me, this
project requires prolonged code gazing sessions, which would only
be interrupted by "instant" communication.  I, and maybe the real
developers, like the fact that email can be consumed /after/ a problem
is investigated/solved.

| Tutoring can not only allow developers that are less intimate with the 
| code become more useful but help ensure the effort they put forward is 
| not only accepted but implemented in an ideal manner.  This is a win for 
| the developers and the project as a whole.  I find it also helps build a 
| level of trust with future submissions from the developer in question. 
| Of course, it also helps build retention with newer developers as it 
| more quickly allows them to feel like they are making a difference.  A 
| key ingredient for any developer that is to stay with any project for 
| the long haul.

This already happens.  There is little hand-holding, but if you 
show that you are standing, someone will likely help you walk.
I have never seen a more helpful, dedicated, intelligent developer
group than this one -- and I have seen a few.  For this reason alone,
the postgresql project will flourish when others wither.

|  Wouldn't it be more helpful to point would-be developers at a specific 
| section of code telling them why they'd want to start there and where 
| any specific documentation is that may be of value?

I agree, a quick-start guide might be helpful, but given the complexity
of this project, a quick-start guide might be more maintenance than
it is worth.  In all honesty, it took me about a month of weekends
to get my head enough into the code that I could find my way around.
If a potential contributor is not willing to show that amount of
initiative, why should the core group think they'll have sufficient
interest to maintain/support any code of theirs that gets into the
codebase?

| Now, I'm not saying we should move away from the mailing list, rather, 
| I'm saying that the core developers way want to reconsider how some 
| requests for help are answered and maybe even consider other forms of 
| complimentary communication.  Doesn't a hour of a core developers time 
| in trade for multiple increase in productivity of another developer seem 
| like a good trade?

An hour of core-developer time might allow you to _not_ learn important
other things that you'll need later.

my $.02 brent

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman

On Tue, Feb 12, 2002 at 09:54:04AM -0600, Greg Copeland wrote:
> I'm new to the list but I'm going to speak up anyways.  Being a core 
> developer on several other projects, I feel that it's important to point 

Welcome. It might have served you better to read some of the archives,
before judging how this community and it's core developers interact.

> out that both comments are valid here.  As a core developer, I certainly 
> don't want to implement seemingly lessor features when more pressing 
> issues are at hand.  At the same time, I would like to see user demand 
> met and have some of the other developers lend a hand while polishing 
> their knowledge on the project in general.  What I've found especially 
> useful has been to tutor and guide (okay, hand-hold) newer/younger 
> developers to my projects so that their abilities are quickly 
> complimented.  I find that using IRC or even other IM technology can go 
> a long way toward providing support for would-be developers.  Especially 
> for projects of this complexity.  I find that this helps well beyond 
> that of a mailing list as people tend to be more timid in a public 
> forum.  After all, it's well understood that a degree of p2p interaction 
> is often very helpful and tends to be even more so as the complexity of 
> the topic grows.

Well, the advantage of the mailing list is that it _is_ a (semi) public
forum: the core developer's time spent answering questions gets multiplied
by the number of potenetial developers listening. And there are archives!

<snip benefits of tutoring>

Well, if you go check the archives (there's that word again) you'll see
that the core developers, and Tom Lane in particular, do a _lot_ of this
kind of tutoring. Both at the initial stage of chosing where to start,
and later, with good feedback of proposed patches.

<tale of trying to directly contact a developer>

well, in this community, this happens on the mailing list. If you're
shy about posting to a list, you won't get along here, anyway. Open
development, open communication.

> 
> Now, I'm not saying we should move away from the mailing list, rather, 
> I'm saying that the core developers way want to reconsider how some 
> requests for help are answered and maybe even consider other forms of 
> complimentary communication.  Doesn't a hour of a core developers time 
> in trade for multiple increase in productivity of another developer seem 
> like a good trade?

Isn't that hour more likely to actually get multiplied if it's spent
responding on the list, where multiple potential coders are listening?

And your more likely to get an answer from _some_ core developer if you
contact them _all_, via the lists. It's a bit rude to go looking for help,
and _insisiting_ on personal service: either direct email or (worse) IRC,
which demands _realtime_ interaction. If the expert suggests changing the
mode of interaction, that's fine.

Ross
-- 
Ross Reedstrom, Ph.D.                                 reedstrm@rice.edu
Executive Director                                  phone: 713-348-6166
Gulf Coast Consortium for Bioinformatics              fax: 713-348-6182
Rice University MS-39
Houston, TX 77005

Greg Copeland <greg@CopelandConsulting.Net> writes:
> [ several useful comments snipped ]

> In fact, I'm happy this came up as I recently emailed a core developer
> asking for places to start as well as any preferred documentation to
> start with.  Basically I was told read the code and go read the docs.

I believe you are complaining about me.  In my defense I'll just say
that your question was basically "how does the optimizer work", which
covers rather a lot of territory.  I didn't see any more useful answer
than the one I gave you, short of writing a book which I was not about
to do in private email.

As I said in that mail and will say again, I believe in carrying on that
sort of discussion in the pgsql-hackers list, where other developers and
wannabee developers have some chance of benefiting from it.  Private mail
only teaches one person.  As for IRC, personally I hate it: it discourages
taking the time for a considered answer, it does not work well for
people in vastly different timezones, and it leaves no archive trail
that others might learn from later.  However, there are other developers
who think differently; I believe you can often find Bruce on IRC, for
example.

The PG community is big enough to support multiple interactions, and if
some folk want to use IRC I have no objection to it.  But I feel that
the hub of the development activity is pgsql-hackers.  There is nothing
wrong with asking questions there.

            regards, tom lane

Ross J. Reedstrom wrote:
> On Tue, Feb 12, 2002 at 09:54:04AM -0600, Greg Copeland wrote:
> 
>>I'm new to the list but I'm going to speak up anyways.  Being a core 
>>developer on several other projects, I feel that it's important to point 
>>
> 
> Welcome. It might have served you better to read some of the archives,
> before judging how this community and it's core developers interact.
> 


Sorry.  Didn't mean for it to sound like I was judging the group.  I was 
only trying to state observations as I've seen them so far and offer a 
suggestion.  I thought I was being constructive.


> 
>>out that both comments are valid here.  As a core developer, I certainly 


[snip]

>>forum.  After all, it's well understood that a degree of p2p interaction 
>>is often very helpful and tends to be even more so as the complexity of 
>>the topic grows.
>>
> 
> Well, the advantage of the mailing list is that it _is_ a (semi) public
> forum: the core developer's time spent answering questions gets multiplied
> by the number of potenetial developers listening. And there are archives!
> 
> <snip benefits of tutoring>
> 
> Well, if you go check the archives (there's that word again) you'll see
> that the core developers, and Tom Lane in particular, do a _lot_ of this
> kind of tutoring. Both at the initial stage of chosing where to start,
> and later, with good feedback of proposed patches.
>

Actually, I have been reading the archives ALOT!  Since they are not 
searchable (searches for me result in nothing happening) it greatly 
limits the accessibility and thusly the usability of them.  As a result 
I've been having to manually browse and read  various threads to see if 
they pertain to anything I'm interested in.  Sorry.


[snip]

> 
> 
>>Now, I'm not saying we should move away from the mailing list, rather, 
>>I'm saying that the core developers way want to reconsider how some 
>>requests for help are answered and maybe even consider other forms of 
>>complimentary communication.  Doesn't a hour of a core developers time 
>>in trade for multiple increase in productivity of another developer seem 
>>like a good trade?
>>>> Isn't that hour more likely to actually get multiplied if it's spent> responding on the list, where multiple
potentialcoders are listening?>
 


Yes and no, depending on the topic and complexity at hand.  Not to 
mention complex conversations that can take weeks to address in email 
can often be addressed in minutes via more interactive mechanisms.


> And your more likely to get an answer from _some_ core developer if you
> contact them _all_, via the lists. It's a bit rude to go looking for help,
> and _insisiting_ on personal service: either direct email or (worse) IRC,
> which demands _realtime_ interaction. If the expert suggests changing the
> mode of interaction, that's fine.


Hmmm.  I didn't think I was asking for personalized service.  In my mind 
I thought I was offering a possible suggestion to a common issue 
(supported by the archives, yes that word again, and a timely posting) 
which was seemingly not well received.

I'll go back and hide in my cave now. :)

Greg

On Tue, Feb 12, 2002 at 05:11:04PM -0600, Greg Copeland wrote:
> 
> 
> Ross J. Reedstrom wrote:
> >On Tue, Feb 12, 2002 at 09:54:04AM -0600, Greg Copeland wrote:
> >
> >>I'm new to the list but I'm going to speak up anyways.  Being a core 
> >>developer on several other projects, I feel that it's important to point 
> >>
> >
> >Welcome. It might have served you better to read some of the archives,
> >before judging how this community and it's core developers interact.
> >
> 
> 
> Sorry.  Didn't mean for it to sound like I was judging the group.  I was 
> only trying to state observations as I've seen them so far and offer a 
> suggestion.  I thought I was being constructive.
> 

Hey, my fault - I came off sounding awfully harsh, myself. I guess I was
triggered by your opening disclaimer sating 'I haven't been here long, but...'

There's been more than one occurance of people showing up and telling the
community how it should run, without seeing how it has run in the past.

> 
> Actually, I have been reading the archives ALOT!  Since they are not 
> searchable (searches for me result in nothing happening) it greatly 
> limits the accessibility and thusly the usability of them.  As a result 
> I've been having to manually browse and read  various threads to see if 
> they pertain to anything I'm interested in.  Sorry.

Yeah, that's not fun. There have been a number of administrative problems
recently with the archive search engine - looks pretty bad when a DB
project has DB backend problems, doesn't it? Sort of a cobbler's children
running barefoot problem. It's being addressed, AFAIR.

> I'll go back and hide in my cave now. :)

No, don't do that! Play out in public, with the rest of us. ;-)

Ross

On Mon, 2002-02-11 at 09:58, Jean-Michel POURE wrote:
> Le Lundi 11 Février 2002 12:33, Gavin Sherry a écrit :
> > The addition of trigger and rule/view
> > recompilation is a convenience at best and there are alternatives to
> > ALTER TABLE DROP COLUMN. Take a look at the TODO list: the most urgent
> > items relate to replication/clustering, point-in-time recovery and
> > row-reuse. All in all, it is these features which are much more desirably
> > to current and prospective users.
>
> Many projects ask users to vote for priority features.
> Who can speak for end-users? Gavin, we need a pool in the to-do-list ...
> These are hackers priorities which ***may** differ from end-user ones.
>
> 1) End-user point of view
>
> My humble and personnal opinion, shared by many end-users, is that CREATE
> TABLE AS (or whatever based on CREATE TABLE AS and UPDATE FROM) is not a
> valid alternative. A database sysadmin with 500 tables, triggers and rules
> cannot use alternatives. We need some basic features :
> - to modify schema objects (CREATE OR REPLACE VIEW, CREATE OR REPLACE
> TRIGGER).
> - to drop schema objects (ALTER TABLE DROP COLUMN).
>
> I would be very please if some users could express themselves. What is your
> opinion as regards CREATE TABLE AS, ALTER TABLE DROP COLUMN, etc...

FWIW, As a user, I still would put my priorities more like Gavin did.
Replication/cluistering is top for me, followed by point-in-time
recovery. Row reuse would be good, although maybe I differ a little in
that I would like 'CREATE OR REPLACE' syntax a liitle more. ALTER TABLE
DROP COLUMN doen't do much for me - it's nice, but for the few case
where my DB design was not up to snuff, I just rename and carry the
column on until my next major upgrade.

Of course my say-so is moot. It's been my experience that people who
vote by suppying code tend to be weight somewhat more hevily in this
process. And I can't think of any way I'd rather have it.

> What is the end-user priority for such features in 7.3 ?
>
> 2) Use of libgda to query legacy databases
>
> Would it be possible to add this feature in the the to-do-list (very low
> priority = in the long run):
> " use libgda to query legacy databases (Oracle, Sybase, MySQL) transparently
> from PostgreSQL in order to access both data (tables, views) and schema
> objects (triggers, functions, rules, types, etc..)".

Easy enough to do in middleware. Just in the fantasy world in which I
somehow spoke for developers' time, I still wouldn't mark this too high
on my priority list.

So there's a little user feedback for you. Hope it helps.

--
Karl DeBisschop
Director, Software Engineering & Development
Learning Network / Information Please
www.learningnetwork.com / www.infoplease.com

On Mon, Feb 11, 2002 at 03:58:43PM +0100, Jean-Michel POURE wrote:

> My humble and personnal opinion, shared by many end-users, is that
> CREATE TABLE AS (or whatever based on CREATE TABLE AS and UPDATE
> FROM) is not a valid alternative. A database sysadmin with 500
> tables, triggers and rules cannot use alternatives. We need some
> basic features :
> - to modify schema objects (CREATE OR REPLACE VIEW, CREATE OR REPLACE
> TRIGGER).
> - to drop schema objects (ALTER TABLE DROP COLUMN).
>
> I would be very please if some users could express themselves. What
> is your opinion as regards CREATE TABLE AS, ALTER TABLE DROP
> COLUMN, etc...

Low priority.  You can work around these limitations without too much
difficulty.  Point-in-time recovery is currently _impossible_.  If
one is going to add features, it is better to concentrate on adding
big, category-killer features than refining little features that can
be worked around.

That said, Postgres is free.  You can do what you like with it.  If
anyone wants to work on "create or replace", &c., s/he is free to do
so.  If it's that important to you, implement it yourself, or pay one
of the able developers to work on a feature you want.  Heck, even if
you pay for the feature to be implemented, it'll cost you less than
Oracle licenses.

--
----
Andrew Sullivan                               87 Mowat Avenue
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110

Greg Copeland wrote:
> I'm new to the list but I'm going to speak up anyways.  Being a core
> developer on several other projects, I feel that it's important to point
> out that both comments are valid here.  As a core developer, I certainly
> don't want to implement seemingly lessor features when more pressing
> issues are at hand.  At the same time, I would like to see user demand
> met and have some of the other developers lend a hand while polishing
> their knowledge on the project in general.  What I've found especially
> useful has been to tutor and guide (okay, hand-hold) newer/younger
> developers to my projects so that their abilities are quickly
> complimented.  I find that using IRC or even other IM technology can go
> a long way toward providing support for would-be developers.  Especially
> for projects of this complexity.  I find that this helps well beyond
> that of a mailing list as people tend to be more timid in a public
> forum.  After all, it's well understood that a degree of p2p interaction
> is often very helpful and tends to be even more so as the complexity of
> the topic grows.

I should add that I am now regularly on AIM, Yahoo, MSN, and ICQ chat as
bmomjian if any coders need assistance.  If there are other chat
protocols people use, let me know.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026