Re: vacuum and row type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: vacuum and row type
Date
Msg-id 16120.1307028466@sss.pgh.pa.us
Whole thread Raw
In response to Re: vacuum and row type  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: vacuum and row type
Re: vacuum and row type
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
>> isn't really specific to ANALYZE.  I'm inclined to think that the most
>> reasonable fix is to make get_sort_group_operators() and related

> Hm, patch is in attach but it doesn't solve all problems. Initial bug is still 
> here for array of row type, but when I tried to change that with recursive call 
> get_sort_group_operators() as it done for row type then 'gmake check' fails 
> because lookup_rowtype_tupdesc fails to find anonymous composite type.

I think we could just let this code assume success for type RECORD.  It
won't affect VACUUM/ANALYZE, since there are (for reasons that should
now be obvious) no table or index columns of anonymous composite types.

What I was thinking last night is that it'd be smart to move all this
logic into the typcache, instead of repeating all the work each time we
make the check.  I'm not convinced that get_sort_group_operators is the
only place we'd have to change if we keep the logic outside the
typcache, anyway.  (I seem to recall there is someplace in the planner
that has a similar check.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: PQdeleteTuple function in libpq
Next
From: HuangQi
Date:
Subject: Re: Hacking gram.y Error syntax error at or near "MERGEJOIN"