From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TODO list updates |
Date: | 2010-03-26 18:53:24 |
Message-ID: | 603c8f071003261153t68034965k49cf5196898f8933@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 26, 2010 at 12:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> In reading through the TODO list, I noticed a few things that I think
>> are done, may be done, or may be partially done. See below.
>> Thoughts? ...Robert
>
>> Add missing operators for geometric data types
>> - this is at least partly done. not sure if it is entirely done.
>
> I think you are thinking of Teodor's point_ops patch, but what that
> did was add GIST index support for some existing geometric operators.
> This TODO item suffers from the all-too-common sin of being uselessly
> vague; it doesn't identify what operators it thinks are missing.
Well, I'm thinking of that because that TODO item has a reference to
the point_ops patch. I think we should remove this item and replace
it with any more specific suggestions someone cares to raise.
>> Implement full support for window framing clauses.
>> - Not sure if we made any progress on this or not.
>
> We made some progress for 9.0, but there's still a lot of unimplemented
> territory.
Perhaps it could be made more specific.
>> Add UNIQUE capability to non-btree indexes
>> - This is one application of exclusion constraints, so I'd say this is done.
>
> I think exclusion constraints address this as much as it needs to be
> addressed for GIST and GIN, neither of which have "equality" as a core
> concept. Hash, however, does have that. So I'd vote for narrowing the
> entry to "support UNIQUE natively in hash indexes" and moving it to the
> hash-index section.
As far as I know, exclusion constraints would work with hash opclasses
also. Do you think there's an advantage to having something that is
hash-specific a la the btree-specific stuff we already have?
>> [GIN] Support empty indexed values (such as zero-element arrays) properly
>> - I think this might be done but I'm not sure.
>
> Not done, not even started. See the referenced discussions, or the
> limitations acknowledged here:
> http://developer.postgresql.org/pgdocs/postgres/gin-limit.html
OK.
>> Clean up VACUUM FULL's klugy transaction management
>> - I think this is moot with the new cluster-based VF.
>
> Right, that one's either done or no longer relevant depending on how you
> want to look at it.
OK.
> There is another TODO item that I was just struck by while reading your
> response to Joseph Adams:
>
> Fix system views like pg_stat_all_tables to use set-returning
> functions, rather than views of per-column functions
>
> What is the point of this proposal? The reason for the per-column function
> implementation was to allow people to slice and dice the underlying data
> their own way. Changing to monolithic SRFs would make that harder, and
> I don't see that it's buying anything especially useful. I'd vote for
> taking this off unless someone can explain why it's an improvement.
I assumed it would be faster and less likely to return inconsistent
results. If that's not the case then I agree.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-03-26 18:59:11 | More idle thoughts |
Previous Message | Tom Lane | 2010-03-26 17:17:57 | Re: last_statrequest is in the future |