Tom Lane <t...@sss.pgh.pa.us> wrote: > Kevin Grittner <kgri...@ymail.com> writes:
>> It's kinda hard for me to visualize where it makes sense to define >> the original table column as the bare type but use a domain when >> referencing it in the view. > > As far as that goes, I think the OP was unhappy about the performance > of the information_schema views, which in our implementation do exactly > that so that the exposed types of the view columns conform to the SQL > standard, even though the underlying catalogs use PG-centric types. > > I don't believe that that's the only reason why the performance of the > information_schema views tends to be sucky, but it's certainly a reason. Is that schema too "edge case" to justify some functional indexes on the cast values on the underlying catalogs? (I'm inclined to think so, but it seemed like a question worth putting out there....) Or, since these particular domains are known, is there any sane way to "special-case" these to allow the underlying types to work? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
