Re: TODO list updates

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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com