Re: TODO list updates - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: TODO list updates |
Date | |
Msg-id | 15389.1269622641@sss.pgh.pa.us Whole thread Raw |
In response to | TODO list updates (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: TODO list updates
Re: TODO list updates Re: TODO list updates |
List | pgsql-hackers |
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. > 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-returningfunctions, 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
pgsql-hackers by date: