Re: 8.2 features status

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 8.2 features status
Date: 2006-08-04 13:46:40
Message-ID: 44D34FC0.9030705@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jonah H. Harris wrote:

> On 8/4/06, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> It's a pity that some expectations have been raised about features that
>> we haven't seen patches for, MERGE/UPSERT & recursive queries
>
>
> Honestly, I've only had four people say it would be nice to have
> hierarchical queries (one of them wasn't even a PostgreSQL user).
> Almost everyone else seems to ask some variation of, "what's a
> hierarchical query and why do I need it?" It's hard to get excited
> about writing a patch no one sees a real need for.
>
> When I have a choice of working on things in my spare time, I choose
> what to work on based on basically two things (a) what is my interest
> in it and (b) who is going to use it. Based on that, I determine
> whether it's worth going through the hassle of design, development,
> testing, and final documentation (my prelim docs come from design).
>
> In short, I know a lot of people would probably use this feature after
> it was there, but *very* few have shown any interest in it and a patch
> for it (while in need of rewriting) has existed since 7.4.
>

Chicken vs. egg. Look at the number of people using nested sets and
other similar abominations to handle hierarchical data. There are whole
books written about using these kludgy techniques. I think this really
is a case of "build it and they will come".

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2006-08-04 13:57:59 Re: 8.2 features status
Previous Message Jonah H. Harris 2006-08-04 13:45:44 Re: standard interfaces for replication providers