Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers