On 27.2.2015 19:50, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>> On 26.2.2015 23:42, Kevin Grittner wrote:
>
>>> One use case is to be able to suppress default display of columns
>>> that are used for internal purposes. For example, incremental
>>> maintenance of materialized views will require storing a "count(t)"
>>> column, and sometimes state information for aggregate columns, in
>>> addition to what the users explicitly request. At the developers'
>>> meeting there was discussion of whether and how to avoid displaying
>>> these by default, and it was felt that when we have this logical
>>> column ordering it would be good to have a way tosuppress default
>>> display. Perhaps this could be as simple as a special value for
>>> logical position.
>>
>> I don't see how hiding columns is related to this patch at all. That's
>> completely unrelated thing, and it certainly is not part of this patch.
>
> It's not directly related to the patch, but I think the intent is that
> once we have this patch it will be possible to apply other
> transformations, such as having columns that are effectively hidden --
> consider for example the idea that attlognum be set to a negative
> number. (For instance, consider the idea that system columns may all
> have -1 as attlognum, which would just be an indicator that they are
> never present in logical column expansion. That makes sense to me; what
> reason do we have to keep them using the current attnums they have?)
My vote is against reusing attlognums in this way - I see that as a
misuse, making the code needlessly complex. A better way to achieve this
is to introduce a simple 'is hidden' flag into pg_attribute, and
something as simple as
ALTER TABLE t ALTER COLUMN a SHOW; ALTER TABLE t ALTER COLUMN a HIDE;
or something along the lines. Not only that's cleaner, but it's also a
better interface for the users than 'you have to set attlognum to a
negative value.'
--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
