Thread: Fetature enhancement request : use of libgda in PostgreSQL to access legacy databases.
Fetature enhancement request : use of libgda in PostgreSQL to access legacy databases.
From
Jean-Michel POURE
Date:
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
Re: Fetature enhancement request : use of libgda in PostgreSQL to access legacy databases.
From
Jean-Michel POURE
Date:
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