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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
