Alvaro Herrera escribió: > Another thing that jumped at me is that passing a TID but not a Relation > is fairly useless as it stands. We might try to add some more stuff > later, such as printing tuple contents as previous versions of the patch > did, but given the opposition the idea had previously, I'm not sure > that's ever going to happen. If we decide that TID-but-not-Relation is > not a useful case, then we can trim the number of messages to translate.
Andres and I chatted a bit about this and came to these conclusions: 1. MyProcPort contains the database name; no need for the get_database_name() call in there. 2. Since this is dealing with tuples obtained from tables, it's hard to see a case where there would be no table or no database. (What does a TID mean without an accompanying relation, anyway?) 3. The MyProcPort thing is initialized quite early in the startup sequence. I don't think it's possible to get to a tuple-lock wait without having the database initialized. Therefore I think the only case worth considering here is when database/relation/TID are all defined. The other cases where there is partial information are dead code; and the case where there is nothing defined (such as the one in SnapBuildFindSnapshot) is already handled by simply not setting up a context at all. 4. There are a few extant get_database_name(MyDatabaseId) calls that could presumably be replaced by MyProcPort->database_name. Or if we want to get cute, hack get_database_name so that if dbid == MyDatabaseId return MyProcPort->database_name. (This would also affect callers of get_database_name that use a value not hardcoded to MyDatabaseId). -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
