jtv
commented
5 years ago I can't think of much to help you with this, I'm afraid... Localisation would be done by the backethnd, before it even gets to libpqxx. Normally you'd want the sqlstate to indicate exactly the nature of the problem. Again, if the backend doesn't supply that information, then libpqxx isn't going to be able to find it for you either.
Is there perhaps some way for your application to check (e.g. by querying the system catalogue) whether the slot is free? It may well be open to race conditions, but perhaps it's better than never knowing.
woelfchen72
Hello, I'm working on a application, that monitors postres logical replication. Everything is sql-driven by pqxx lib. In some seldom cases I have the problem, that I cant create a so called subscription (on sibscriber node), because the publishers node has an old replication slot with that name. This is not a problem, I can delete this old slot. My problem is, to detect this special case. I catch an exception of the type pqxx::sql_error. I checked it in runtime with typeid(...). But the sqlstate() of it always is "XX000", like on other runtime errors. So I can't select it from other runtime-errors (i.e. "No connection from subscriber node to publisher node", which is a pqxx::sql_error with sqlstate() == "XX000" too). The only way is to compare the what() string, but it is localized, so I think its not a good idea, because we have different localizations on out target systems (german or english). So: is the a way to an "unlocalized" what(), or is there another parameter of the exception to sort them apart? Thank you.