Re: TODO list updates

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.

> 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.

> 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.

> [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

> 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.

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.

regards, tom lane