Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Increased company involvement

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: David Fetter <david(at)fetter(dot)org>
Cc: "Nicolai Petri (lists)" <lists(at)petri(dot)cc>,"Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Kris Jurka <books(at)ejurka(dot)com>,Andrew Dunstan <andrew(at)dunslane(dot)net>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] Increased company involvement
Date: 2005-05-01 01:34:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacypgsql-hackers
On Saturday 30 April 2005 17:40, David Fetter wrote:
> On Sat, Apr 30, 2005 at 10:37:06AM +0200, Nicolai Petri (lists) wrote:
> > I totally agree. In our preference list I would have the following tasks
> > : 1)  IOT (Index Ordered Tables)
> Is this different from CLUSTER?

I think what he is looking for is a table that is maintained in CLUSTERed 
order... ie. new inserts will be put in the appropriate place mimicing what 
happens with indexes.  This has been discussed in the past and has been shot 
down before...see archives on pgsql-hackers for past discussions. 

> > 4)  Extending PostgreSQL's plugin support with additional hooks in the
> >      backend e.g. :
> >       - for adding new tablestore engines (like mysql can)

my$ql's multiple table handlers is about the ugliest hack I have ever seen 
inside a database.  I mean I used to not like it, but I've been studying it a 
little bit lately and now find it absolutly dreadfull.  I can't imagine that 
we would ever implement a scheme like the one they have used; whatever 
advantage people think they can gain from such a setup can probably be 
implemented in a cleaner fasion in postgresql assuming it would be an 
advantage at all (and some of those features have been dismissed in the past 
as well so there's no garauntee)

> >       - for adding callbacks that get's called on transaction
> > success/failure using SPI. (e.g. for housekeeping and cleanup)
> Would this be like an ON COMMIT TRIGGER?
Another idea I have seen shot down on hackers a number of times...  

The point of this email being that, I think the general idea probably needs to 
be that any coordinated community sponsored development needs to be centered 
on picking your favorite items from the TODO list to be worked on rather than 
just specifying a list of things you think should be the top priorities. Of 
course there is nothing preventing people from getting new items added to the 
todo list, but as a general guidline picking items from the todo gets you 
halfway home right out of the gate. 

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

In response to

pgsql-hackers by date

Next:From: James William PyeDate: 2005-05-01 01:37:20
Subject: pl/Python
Previous:From: Mischa SandbergDate: 2005-04-30 23:41:26
Subject: OLAP and PG and deja-vu

pgsql-advocacy by date

Next:From: Robert TreatDate: 2005-05-01 01:40:46
Subject: Re: [HACKERS] Increased company involvement
Previous:From: David FetterDate: 2005-04-30 21:40:04
Subject: Re: [HACKERS] Increased company involvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group