On Sun, Feb 6, 2011 at 8:58 AM, Noah Misch <n...@leadboat.com> wrote: > On Sun, Feb 06, 2011 at 08:40:44AM -0500, Noah Misch wrote: >> On Sun, Feb 06, 2011 at 07:54:52AM -0500, Robert Haas wrote: >> > Yeeeeeeah, that's actually a little ugly. It's actually a domain >> > over a composite type, not a composite type proper, IIUC. Better >> > ideas? >> >> There are no domains over composite types. get_rels_with_domain() finds all >> relations having columns of the (scalar) domain type. It then calls >> find_composite_type_dependencies to identify uses of the composite types >> discovered in the previous step. >> >> Honestly, RELKIND_COMPOSITE_TYPE is a reasonable choice despite the technical >> mismatch. One more-correct approach would be to have two arguments, a >> catalog >> OID (pg_type or pg_class, currently) and a relkind, 0 when the catalog OID != >> pg_class. Might be an improvement, albeit a minor one. > > Scratch that. How about classid and objid arguments, passing them to > getObjectionDescription() internally? We already do something very similar in > ATExecAlterColumnType for a related case.
That's not quite so good for translators, I think. Another option is that we could just say "relation" (table, foreign table, etc...) or "type". We use the word relation as a more generic version of table in a few other places. -- Robert Haas EnterpriseDB: 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
