On 2 April 2015 at 19:15, Taylor Brown <taylor@xxxxxxxxxxxxxxxxxx> wrote:
--
So, I would rather put a check like this at the top of my function:--important_variable = (p_request::json->>'important_variable')::integer;
IF (important_variable is NULL) THEN RAISE EXCEPTION 'important_variable must not be NULL.'; END IF;
--But I won't be able to get the context for that exception, and all I'll be able to return from the function or write to the logs is 'important_variable must not be NULL.'. If that's the only place I throw that error, I'll know where to look. Otherwise, I have no context, and won't be able to determine where my exception was thrown. So I'm actually better off _not_ throwing my own custom exceptions, even though I would prefer to be more defensive about this sort of thing in my code.I thought I might be able to "trick" postgres into throwing another unrelated exception that would not only include my custom error message, but allow me to extract the context, telling me the function where I should begin debugging.
Just a quick idea, but... Perhaps you could put a constraint on those JSON messages indirectly, by mapping it to some kind of template table?
The top-level of a JSON message can usually be mapped to a table, and a table can have constraints and, for example, a BEFORE INSERT trigger that always returns NULL so that the data is not actually inserted into the table.
The top-level of a JSON message can usually be mapped to a table, and a table can have constraints and, for example, a BEFORE INSERT trigger that always returns NULL so that the data is not actually inserted into the table.
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
Cut the trees and you'll see there is no forest.
