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