The problem is that after a dump and reload of
a table hierarchy there are different values in
pg_attribute.attislocal.

A quick grep shows few references to attislocal.
But I cannot say for sure it is unused since it is
documented. However, I'm looking at a db diff
tool and there it does matter.

This is the setup:

I've got an inheritance hierarchy, answer_values
with a bunch of answer_[type] tables inheriting
from it.

tiny=# \d answer_values
Table "public.answer_values"
Column | Type | Modifiers
--------+---------+-----------------------------------------------------------------
orid | integer | not null
qid | integer | not null
avid | integer | not null default nextval('public.answer_values_avid_seq'::text)
atype | text |
ncols | integer |
Indexes:
"answer_values_pkey" PRIMARY KEY, btree (orid, qid, avid)

tiny=# \d answer_text
Table "public.answer_text"
Column | Type | Modifiers
--------+---------+----------------------------------------------------------
orid | integer | not null
qid | integer | not null
avid | integer | not null default nextval('answer_values_avid_seq'::text)
atype | text |
ncols | integer |
avalue | text |
Indexes:
"answer_text_pk" UNIQUE, btree (avid)
Inherits: answer_values


* In 8.0.4,
* created a clean db (tiny) and loaded the SQL to define the hierarchy.
* pg_dump tiny > tiny.dat
* createdb tiny2
* psql < tiny.dat

After this, looking at the 'avid' attribute in the
pg_attribute table all of tables loaded in the second
db have 't' for attislocal. This is different from
the original definition.


tiny=# select r.relname, attname, attislocal, attinhcount from pg_attribute a join pg_class r ON (a.attrelid = r.oid) where attname = 'avid' order by relname;
relname | attname | attislocal | attinhcount
----------------------+---------+------------+-------------
answer_addr | avid | f | 1
answer_addr_pk | avid | t | 0
answer_bool_pk | avid | t | 0
answer_boolean | avid | f | 1
answer_date | avid | f | 1
answer_date_pk | avid | t | 0
answer_date_range | avid | f | 1
answer_dater_pk | avid | t | 0
answer_float | avid | f | 1
answer_flt_pk | avid | t | 0
answer_num_pk | avid | t | 0
answer_numeric | avid | f | 1
answer_numeric_range | avid | f | 1
answer_numr_pk | avid | t | 0
answer_text | avid | f | 1
answer_text_pk | avid | t | 0
answer_values | avid | t | 0
answer_values_pkey | avid | t | 0
av_v | avid | t | 0
(19 rows)

tiny2=# select r.relname, attname, attislocal, attinhcount from pg_attribute a join pg_class r ON (a.attrelid = r.oid) where attname = 'avid' order by relname;
relname | attname | attislocal | attinhcount
----------------------+---------+------------+-------------
answer_addr | avid | t | 1
answer_addr_pk | avid | t | 0
answer_bool_pk | avid | t | 0
answer_boolean | avid | t | 1
answer_date | avid | t | 1
answer_date_pk | avid | t | 0
answer_date_range | avid | t | 1
answer_dater_pk | avid | t | 0
answer_float | avid | t | 1
answer_flt_pk | avid | t | 0
answer_num_pk | avid | t | 0
answer_numeric | avid | t | 1
answer_numeric_range | avid | t | 1
answer_numr_pk | avid | t | 0
answer_text | avid | t | 1
answer_text_pk | avid | t | 0
answer_values | avid | t | 0
answer_values_pkey | avid | t | 0
av_v | avid | t | 0
(19 rows)


----- End forwarded message -----

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hi Elein,

elein wrote:

It's not unused, though it's not a hot spot (it's only used to prevent
you from dropping an inherited column). I can't reproduce your problem
here though -- the dump comes out just like the tables I produced. Care
to provide the original SQL script?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend