Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think the OID is better than the name, but if it's easy to pass the
> name and schema, then I'm fine with it.  But I do think this is one of

It's quite easy to get name and schema from the command yes, here's an
example of how I'm doing it for some commands:

		case T_CreateStmt:
		{
			CreateStmt *node = (CreateStmt *)parsetree;
			cmd->schemaname = RangeVarGetNamespace(node->relation);
			cmd->objectname = node->relation->relname;
			break;
		}

		case T_AlterTableStmt:
		{
			AlterTableStmt *node = (AlterTableStmt *)parsetree;
			cmd->schemaname = RangeVarGetNamespace(node->relation);
			cmd->objectname = node->relation->relname;
			break;
		}

		case T_CreateExtensionStmt:
		{
			cmd->schemaname = NULL;
			cmd->objectname = ((CreateExtensionStmt *)parsetree)->extname;
			break;
		}

Getting the OID on the other hand is much harder, because each command
implements that part as it wants to, and DefineWhatever() functions are
returning void. We could maybe have them return the main Oid of the
object created, or we could have the CommandContext structure I'm using
be a backend global variable that any command would stuff.

In any case, adding support for the OID only works for after trigger
when talking about CREATE commands and for before trigger if talking
about DROP commands, assuming that the trigger procedure is run after
we've been locating said Oid.

It seems to me to be a couple orders of magnitude more work to get the
Oid here compared to just get the schemaname and objectname. And getting
those works in all cases as we take them from the command itself (we
fill in the schema with the first search_path entry when it's not given
explicitly in the command)

 CREATE TABLE foo();
 NOTICE:  tag:  CREATE TABLE
 NOTICE:  enforce_local_style{public.foo}: foo

> those problems that is complex enough that we should be happy to get
> the core infrastructure in in the first commit, even with an extremely
> limited amount of functionality, and then build on it.
> Enhance-and-extend is so much easier than a monolithic code drop.

I'm happy to read that, and I'm preparing next patch version (v6) with
that goal in mind.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

In response to

• Re: Command Triggers at 2012-01-20 15:03:53 from Robert Haas

Responses

• Re: Command Triggers at 2012-01-20 18:14:20 from Robert Haas

pgsql-hackers by date

Next:	From: Kevin Grittner	Date: 2012-01-20 17:30:41
	Subject: Re: Remembering bug #6123
Previous:	From: David E. Wheeler	Date: 2012-01-20 17:14:35
	Subject: Re: JSON for PG 9.2