Heikki:
Thanks for the response. I am writing an external replication engine
and putting hooks into postgres to send "signals" via a unix socket to
the outside world.
All of the logic and implementation will occur OUTSIDE the postgres
codebase and
will not interfere with any WAL based replication schemes.
The usual "Trigger" level asynch replication does on not suffice since
it does not handle
new databases, new schemas, new tables, new indexes, alter everything,
new functions, etc.
So I started putting into utility.c->xxx_ProcessUtility(..., stmt*
parsetree,....) so that discrete
Does anybody have other ideas where to better locate the "Hooks" for
external replication/signaling
than utility.c?
One drawback is that I have to patch directly into those areas where new
relation IDs are created
so I can pass them outside of the process to the replication engine.
Process Utility does a really bad job of retaining
its work as it processes the statements, so I have to patch code where
the relation IDS are created. Those new IDS are never retained
when leaving ProcessUtility, its work is done.
Is there a way to put a "Trigger" on pg_class, pg_database, pg_namespace
instead of patching the statically
compiled binary to simulate the triggers?
Cheers,
marco
On 9/21/2012 10:15 AM, Heikki Linnakangas wrote:
On 21.09.2012 17:58, m...@rpzdesign.com wrote:
During the execution of ProcessUtility() function in
/src/backend/xxx/utility.c,
the CreateStmt node type is processed to create a table.
Is there a global function in the context of the backend process that
will deliver what the current database and schema names?
There's a global variable MyDatabaseId for the database the backend is
connected to. It doesn't change after login.
There's no such thing as a "current schema", but I think you'll want
to take a look at src/backend/catalog/namespace.c, which handles the
search_path. There's a variable activeCreationNamespace there; look at
the functions in namespace.c to see how it works.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
