Tom Lane wrote:
> Robert Haas <robertmh...@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.
The full TODO item text is:
Add missing operators for geometric data types
Some geometric types do not have the full suite of geometric
operators, e.g. box @> point
* point_ops for GiST
but we now have the @> operator mentioned:
pg_catalog | @> | box | point | boolean |
contains?
so I have removed this TODO item.
> > 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.
Agreed, moved.
> > 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.
Agreed, removed.
> 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.
Agreed, removed. I wasn't aware why we implemented this as slices. I
now assume it was for performance reasons.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
