On Wed, Apr 5, 2023 at 11:34 AM Pavel Stehule <pavel.steh...@gmail.com> wrote: > If the GUC_REPORT should not be used, then only one possibility is enhancing > the protocol, about the possibility to read some predefined server's features > from the client. > It can be much cheaper than SQL query, and it can be used when the current > transaction is aborted. I can imagine a possibility to read server time or a > server session role from a prompt processing routine. > > But for this specific case, you need to cache the role name somewhere. You > can simply get oid everytime, but for role name you need to access to system > catalogue, and it is not possible in aborted transactions. So at the end, you > probably should read "role" GUC. > > Can this design be acceptable?
I don't think we want to add a dedicated protocol message that says "send me the role GUC right now". I mean, we could, but being able to tell the GUC mechanism "please send me the role GUC after every command" sounds a lot easier to use. -- Robert Haas EDB: http://www.enterprisedb.com
