Table inheritance and column ordering question
Hi all,
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 foo
Table "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 foo
Table "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
Is what I am thinking of worth pursuing? Or does it misuse the concept of
inheritance in the postgres context?
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