Future is always administerable especially when there are not problems
in the present!
The reasons I am not in favour of it:
1) Writing for second time the column names is a "repeat yourself"
(that makes me really sick!),
2) The possibility of adding attributes into columns is a good feature
(at least not bad one) which can help a lot,
3) Imagine that is_nullable (NULL attribute) did not exist. I am sure
that you could survive; but how easier it makes your life, that now it
does exist,
4) Some columns additional to the existing ones cost nothing when
there is a good purpose, especially when there ara plenty of them in
the vicinity which most of the times are empty but, of course, serving
a good purpose!
5) Kind dispute is always a good resource of new ideas,
6)There is always a space of improvement and better solution (Ah, how
haven't I thought it before?) especially in IT "art" sector.
So, adding an extra boolean column to "information_schema.columns" or
"pg_attribute" will cause any "fatal" problem in the present?
Krgds
On 12/30/17, PT <wmoran@potentialtech.com> wrote:
> On Sat, 30 Dec 2017 20:33:28 +0100
> GPT <gptmailinglists@gmail.com> wrote:
>
>> Please visit the following link:
>>
>> https://stackoverflow.com/q/48028501/8895614
>>
>> but thing may go further/deeper than it seems.
>
> Adding columns to a built-in system table is liable to cause all sorts of
> problems in the future: when you upgrade, migrate to another server, need
> to
> create dev environments, etc.
>
> The view technique described in the stackunderwhelm article seems like
> a good solution to me. Maybe if you could explain why you are against
> it?
>
>> Krds
>>
>> On 12/30/17, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:
>> > On Sat, Dec 30, 2017 at 08:17:34PM +0100, GPT wrote:
>> >
>> >> I would like to add an extra boolean attribute to table columns,
>> >> something like NULL. Unfortunately Pg does not support such a feature:
>> >>
>> >> ADD ATTRIBUTE <attribute_name> TYPE <type_of_attribute> TO COLUMN
>> >> <schema.table.column_name>;
>> > ...
>> >> I have already been suggested to use VIEW or dynamic SQL but I am
>> >> looking something different.
>> >
>> > Can you explain why ?
>> >
>> > One thing that comes to mind is complex user types.
>> >
>> > Or columns of type table.
>> >
>> > Karsten
>> > --
>> > GPG key ID E4071346 @ eu.pool.sks-keyservers.net
>> > E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
>> >
>> >
>>
>
>
> --
> Bill Moran
>