Hi, > v3 also fixes a nasty uninitialized stack variable, along with a bad > collation assumption I made.
I decided to take a closer look at 0001. Since pg_get_relation_publishing_info() is exposed to the users I think it should be described in a bit more detail than: ``` + descr => 'get information on how a relation will be published via a list of publications', ``` This description in \df+ output doesn't seem to be particularly useful. Also the function should be documented. In order to accomplish all this it could make sense to reconsider the signature of the function and/or split it into several separate functions. The volatility is declared as STABLE. This is probably correct. At least at first glance I don't see any calls of VOLATILE functions and off the top of my head can't give an example when it will not behave as STABLE. This being said, a second opinion would be appreciated. process_relation_publications() misses a brief comment before the declaration. What are the arguments, what is the return value, are there any pre/postconditions (locks, memory), etc. Otherwise 0001 is in a decent shape, it passes make installcheck-world, etc. I would suggest focusing on delivering this part, assuming there will be no push-back to the refactorings and slight test improvements. If 0002 could be further decomposed into separate iterative improvements this could be helpful. -- Best regards, Aleksander Alekseev