Re: ALTER TYPE 2: skip already-provable no-work rewrites

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TYPE 2: skip already-provable no-work rewrites
Date: 2011-02-06 13:58:30
Message-ID: 20110206135830.GC16927@tornado.gateway.2wire.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-06 14:10:15 Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Previous Message Noah Misch 2011-02-06 13:47:54 Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql