On Wed, Jan 15, 2020 at 6:40 PM Andres Freund <and...@anarazel.de> wrote: > It's not obvious why the better approach here wouldn't be to just have a > very simple ereport replacement, that needs to be explicitly included > from frontend code. It'd not be meaningfully harder, imo, and it'd > require fewer adaptions, and it'd look more familiar.
I agree that it's far from obvious that the hacks in the patch are best; to the contrary, they are hacks. That said, I feel that the semantics of throwing an error are not very well-defined in a front-end environment. I mean, in a backend context, throwing an error is going to abort the current transaction, with all that this implies. If the frontend equivalent is to do nothing and hope for the best, I doubt it will survive anything more than the simplest use cases. This is one of the reasons I've been very reluctant to go do down this whole path in the first place. > > +#ifdef FRONTEND > > + lex->token_terminator = s + > > PQmblen(s, PG_UTF8); > > +#else > > lex->token_terminator = s + > > pg_mblen(s); > > +#endif > > If we were to go this way, it seems like the ifdef should rather be in a > helper function, rather than all over. Sure... like I said, this is just to illustrate the problem. > It seems like it should be > unproblematic to have a common interface for both frontend/backend? Not sure how. pg_mblen() and PQmblen() are both existing interfaces, and they're not compatible with each other. I guess we could make PQmblen() available to backend code, but given that the function name implies an origin in libpq, that seems wicked confusing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
