TODO list updates

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.

Add OR REPLACE to CREATE LANGUAGE
- Done.

Implement full support for window framing clauses.
- Not sure if we made any progress on this or not.

Add PQescapeIdentifierConn()
- Done, as PQescapeIdentifier().

Add UNIQUE capability to non-btree indexes
- This is one application of exclusion constraints, so I'd say this is done.

[GIN] Support empty indexed values (such as zero-element arrays) properly
- I think this might be done but I'm not sure.

Clean up VACUUM FULL's klugy transaction management
- I think this is moot with the new cluster-based VF.

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

On Fri, Mar 26, 2010 at 12:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> As far as I know, exclusion constraints would work with hash opclasses
> also.

Yeah, they do.

> Do you think there's an advantage to having something that is
> hash-specific a la the btree-specific stuff we already have?

Sure: it'll be more efficient because of not needing an AFTER trigger.
Now of course this assumes that hash indexes ever grow up enough to play
in the big leagues, which is a pretty dubious proposition; but having
real unique-constraint support is one of the things people would want
from them if they ever did get to be credible production choices.
So this isn't something I'd put at the front of the TODO list for hash
indexes, but it ought to be in there somewhere.

regards, tom lane

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

Robert Haas wrote:
> 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.
>
> Add OR REPLACE to CREATE LANGUAGE
> - Done.

TODO updated.

> Add PQescapeIdentifierConn()
> - Done, as PQescapeIdentifier().

TODO updated.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

2010/3/27 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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
>
>> 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.

TODO updated.

--
Hitoshi Harada