On Thu, Jan 16, 2020 at 1:37 PM David Steele <da...@pgmasters.net> wrote: > I was starting to wonder if it wouldn't be simpler to go back to the > Postgres JSON parser and see if we can adapt it. I'm not sure that it > *is* simpler, but it would almost certainly be more acceptable.
That is my feeling also. > So the idea here is that json.c will have the JSON SQL functions, > jsonb.c the JSONB SQL functions, and jsonapi.c the parser, and > jsonfuncs.c the utility functions? Uh, I think roughly that, yes. Although I can't claim to fully understand everything that's here. > This seems like a good first step. I wonder if the remainder of the SQL > json/jsonb functions should be moved to json.c/jsonb.c respectively? > > That does represent a lot of code churn though, so perhaps not worth it. I don't have an opinion on this right now. > Well, with the caveat that it doesn't work, it's less than I expected. > > Obviously ereport() is a pretty big deal and I agree with Michael > downthread that we should port this to the frontend code. Another possibly-attractive option would be to defer throwing the error: i.e. set some flags in the lex or parse state or something, and then just return. The caller notices the flags and has enough information to throw an error or whatever it wants to do. The reason I think this might be attractive is that it dodges the whole question of what exactly throwing an error is supposed to do in a world without transactions, memory contexts, resource owners, etc. However, it has some pitfalls of its own, like maybe being too much code churn or hurting performance in non-error cases. > It would also be nice to unify functions like PQmblen() and pg_mblen() > if possible. I don't see how to do that at the moment, but I agree that it would be nice if we can figure it out. > The next question in my mind is given the caveat that the error handing > is questionable in the front end, can we at least render/parse valid > JSON with the code? That's a real good question. Thanks for offering to test it; I think that would be very helpful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
