Re: enhanced error fields
От | Pavel Stehule |
---|---|
Тема | Re: enhanced error fields |
Дата | |
Msg-id | CAFj8pRB=HDu9JvgjSHwKdRHH6zyjPxw8WMkyRiEmhj60muejeg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: enhanced error fields (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2012/12/29 Tom Lane <tgl@sss.pgh.pa.us>: > Peter Geoghegan <peter@2ndquadrant.com> writes: >> On 29 December 2012 05:04, Pavel Stehule <pavel.stehule@gmail.com> wrote: >>>> So I'm with Peter G on this: the existing CONTEXT mechanism is good >>>> enough, we do not need to split out selected sub-parts of that as >>>> separate error fields. Moreover, doing so would provide only an utterly >>>> arbitrary subset of the context stack: who's to say whether it would be >>>> more important to report the most closely nested function, or the >>>> outermost one? > >>> I don't agree with this argument - you can say too "COLUMN_NAME, >>> TABLE_NAME" is not necessary, because MESSAGE is good enough. I don't >>> see any difference - and I would to use these variables for error >>> handling (not for logging) without dependency on current format of >>> MESSAGE or CONTEXT. > >> In my judgement, COLUMN_NAME and TABLE_NAME can be used without having >> an unreasonable degree of coupling between client and server-side >> code. > > Yeah, I was about to reply in almost exactly those words. Table and > column names are, almost by definition, part of the shared understanding > of the client-side and server-side portions of any application, because > both sides have to manipulate those in order to do anything. However, > if client-side code were to rely on something like ROUTINE_NAME for > error processing, it would become closely tied to the *code structure* > of the server-side functions, which is a bad idea. > > Basically the value proposition here is "let's contort the backend code > in order to support very bad programming practices in applications". > I'm not attracted by either part of that. I don't think so it is necessary bad practice. first - my motivation is related primary for usage in PL/pgSQL. we can handle exceptions very near to place where exception was raised. And then I can take same information like ROUTINE_NAME. Later I can forward exception. A disadvantage of this design is higher number of subtransactions. Other design, I talked about it - is based on one relative high positioned subtransaction, where I can handle lot of types of exceptions or can raise final exception. I can do same work as in previous mentioned design but just with one subtransaction. But for design I need a data. And if is possible in simple form - because it is better for PL/pgSQL. > >> I don't think there should be a TRIGGER_NAME either - I think that we >> should make interfaces easy to use correctly, and hard to use >> incorrectly, and a mechanised response to a TRIGGER_NAME seems >> incorrect. If you think that there should be a trigger name within >> CONTEXT, there might be a case to be made for that, but I would prefer >> to have that reviewed separately. > > If the calling of a trigger isn't visible in the CONTEXT stack then > that's something we should address --- but in practice, wouldn't it be > visible anyway as an ordinary function call? At least if the trigger > is written in a reasonable PL. If the trigger is written in C, then > I'm outright against adding any such overhead. I don't think this patch > should be adding any cycles whatsoever to non-error code paths. > visibility in CONTEXT depends on creating and registering error callbacks - I don't would to change it. Regards Pavel > regards, tom lane
В списке pgsql-hackers по дате отправления: