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
