On Tue, Jan 5, 2010 at 4:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 29, 2009 at 9:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Yep. It would also lower the barrier to future innovations of that
>>> type, which would be a good thing, IMO. Unfortunately we'd likely
>>> need to continue to support the existing syntax at least for
>>> attstattarget, which is kind of a bummer, but seems managable. I
>>> think we could throw over the syntax for ALTER TABLE ... ADD
>>> STATISTICS DISTINCT since it is an 8.5-ism.
>>
>> Yeah --- if we think we might want to do this, now is the time,
>> before we're stuck with supporting that syntax. (I was thinking
>> earlier today that attdistinct was already in 8.4, but it's not.)
>
> [ Hack, hack, hack. ]
>
> I'm not quite sure what the correct approach is to making attoptions
> available to examine_attribute(), which can't get at them in any very
> obvious way because the relation descriptor it gets passed as an
> argument only includes the fixed-size portion of each pg_attribute
> tuple. The obvious approaches are:
>
> 1. Extract attrelid and attnum from the tuple and issue a syscache
> lookup to get the full tuple.
> 2. Make RelationBuildTupleDesc() parse the attoptions and store them
> into a new RelationData member.
>
> I'm leaning toward the latter method.
Upon further study, this does not look easy at all. There are complex
assumptions embedded in this code about what aspects of an index can
change on the fly and how those changes must be handled. Trying to
modify this seems likely to lead to (1) a further increase in code
complexity and (2) breakage.
I'm thinking maybe the best approach here is to store this information
in a separate cache indexed by <attrelid, attnum>.
...Robert