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@xxxxxxxxxxxxxxxxx> wrote: > On Sat, 30 Dec 2017 20:33:28 +0100 > GPT <gptmailinglists@xxxxxxxxx> 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@xxxxxxx> 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 >
