Thread: Re: [HACKERS] Feature enhancement request : use of libgda in
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
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
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
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
> 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
Hi, Is anybody on this list involved in the courier, or shipping industry? Please reply off list. Dave