Обсуждение: Table inheritance and column ordering question
Hi all,
Is what I am thinking of worth pursuing? Or does it misuse the concept of inheritance in the postgres context?
I hope this is the right list for my question, if not, please let me know to which list I should send the question.
I'd like to know whether there is any way to control the order of inherited columns?
This is purely an issue of syntactic sugar for me. I'd like to be able to do the following:
create table my_standard_metadata (created_ts timestamp default now() not null, updated_ts timestamp, deactived_ts timestamp);create table foo (field1 text, field2 text) inherits (my_standard_metadata);
Currently, this results in:
postgres=# \d fooTable "public.foo"Column | Type | Collation | Nullable | Default--------------+-----------------------------+-----------+----------+---------created_ts | timestamp without time zone | | not null | now()updated_ts | timestamp without time zone | | |deactived_ts | timestamp without time zone | | |field1 | text | | |field2 | text | | |Indexes:"foo_pkey" PRIMARY KEY, btree (email)Inherits: my_standard_metadata
and have the resulting table be described as follows
postgres=# \d fooTable "public.foo"Column | Type | Collation | Nullable | Default--------------+-----------------------------+-----------+----------+---------field1 | text | | |field2 | text | | |created_ts | timestamp without time zone | | not null | now()updated_ts | timestamp without time zone | | |deactived_ts | timestamp without time zone | | |Indexes:"foo_pkey" PRIMARY KEY, btree (email)Inherits: my_standard_metadata
Thanks for any thoughts!
-Steve
Stephan Doliov <stephan.doliov@gmail.com> writes: > I'd like to know whether there is any way to control the order of inherited > columns? Nope, not at present. There's a lot of wished-for functionality around separating the presentation order of table columns from their physical storage order. If we had that it'd fix your problem too. But right now, those are tied together and also tied to the columns' catalog identifiers (attno). People have investigated changing that, but it looks enormously bug-prone since the existing code doesn't distinguish these concepts. regards, tom lane