Re: TODO list updates - Mailing list pgsql-hackers

On Fri, Mar 26, 2010 at 12:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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