Re: [HACKERS] [PATCH] SQL function to report log message

Hi All, On Tue, Nov 17, 2015 at 12:10 PM, Peter Eisentraut wrote: > On 11/17/15 2:16 AM, Jim Nasby wrote: > > On 11/15/15 10:56 PM, dinesh kumar wrote: > >> So, shall we make this pg_report_log TO pg_write_log OR pg_ereport OR > >> from you. > > > > Why not pg_raise to mirror

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Nov 16, 2015 at 5:41 PM, Peter Eisentraut wrote: > On 11/16/15 5:10 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> On 11/15/15 9:50 PM, Craig Ringer wrote: I'd prefer to omit fields if explicitly assigned to NULL. You can always use

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/17/15 2:16 AM, Jim Nasby wrote: > On 11/15/15 10:56 PM, dinesh kumar wrote: >> So, shall we make this pg_report_log TO pg_write_log OR pg_ereport OR >> from you. > > Why not pg_raise to mirror plpgsql? (The function does have the same > semantics, right? It's not doing something like only

Re: [HACKERS] [PATCH] SQL function to report log message

On Sunday, November 15, 2015 8:51 PM, Craig Ringer wrote: > I'd prefer to omit fields if explicitly assigned to NULL. You can > always use coalesce if you want the string 'NULL'; I agree with > others here that the vast majority of users will want the field > just

Re: [HACKERS] [PATCH] SQL function to report log message

Peter Eisentraut writes: > On 11/15/15 9:50 PM, Craig Ringer wrote: >> I'd prefer to omit fields if explicitly assigned to NULL. You can always >> use coalesce if you want the string 'NULL'; I agree with others here >> that the vast majority of users will want the field just

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/16/15 5:10 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 11/15/15 9:50 PM, Craig Ringer wrote: >>> I'd prefer to omit fields if explicitly assigned to NULL. You can always >>> use coalesce if you want the string 'NULL'; I agree with others here >>> that the vast

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/15/15 9:50 PM, Craig Ringer wrote: > On 16 November 2015 at 09:50, Peter Eisentraut > wrote: > > > I haven't seen this discussed before, but I don't find the name > pg_report_log particularly good. Why not jut pg_log? > > > Sounds like

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Nov 16, 2015 at 3:58 PM, Kevin Grittner wrote: > On Sunday, November 15, 2015 8:51 PM, Craig Ringer > wrote: > > > I'd prefer to omit fields if explicitly assigned to NULL. You can > > always use coalesce if you want the string 'NULL'; I agree

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/15/15 10:56 PM, dinesh kumar wrote: So, shall we make this pg_report_log TO pg_write_log OR pg_ereport OR from you. Why not pg_raise to mirror plpgsql? (The function does have the same semantics, right? It's not doing something like only sending to the log and not the client?) -- Jim

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/22/15 3:20 AM, dinesh kumar wrote: > + > + > + > pg_report_log(logleveltext, > message anyelement[, ishidestmt > boolean ] [, detail text] [, > hint text] [, sqlstate > text]) > + > + void > + > +Report message or error. > + > +

Re: [HACKERS] [PATCH] SQL function to report log message

On 16 November 2015 at 09:50, Peter Eisentraut wrote: > > > I haven't seen this discussed before, but I don't find the name > pg_report_log particularly good. Why not jut pg_log? > > Sounds like a better name to me. 'report' is noise that adds nothing useful. I'd like to have

Re: [HACKERS] [PATCH] SQL function to report log message

Hi, On Mon, Nov 16, 2015 at 2:50 AM, Peter Eisentraut wrote: > On 10/22/15 3:20 AM, dinesh kumar wrote: > > + > > + > > + > pg_report_log(logleveltext, > message anyelement[, ishidestmt > boolean ] [, detail text] [, > hint text] [, sqlstate > text]) > > +

Re: [HACKERS] [PATCH] SQL function to report log message

Hi All, On Tue, Oct 20, 2015 at 1:22 PM, Pavel Stehule wrote: > > 2015-10-20 20:05 GMT+02:00 Robert Haas : > >> On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule >> wrote: >> > 2015-10-20 17:15 GMT+02:00 Robert Haas

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Oct 22, 2015 at 11:15 AM, Jim Nasby wrote: > On 10/22/15 2:20 AM, dinesh kumar wrote: > >> >> 2. Using this function, if we provide any "NULL" argument to the function, >> we should either skip it or report it. I see this is what the function >> is doing. >>

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/22/15 2:20 AM, dinesh kumar wrote: 2. Using this function, if we provide any "NULL" argument to the function, we should either skip it or report it. I see this is what the function is doing. postgres=# SELECT pg_report_log('INFO', 'NULL', false, NULL, NULL); INFO: NULL postgres=#

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/22/15 3:20 AM, dinesh kumar wrote: > postgres=# SELECT pg_report_log('INFO', 'NULL', false, NULL, NULL); > INFO: NULL > > postgres=# SELECT pg_report_log('INFO', 'NULL', false, 'NULL', 'NULL'); > INFO: NULL > DETAIL: NULL /-- Are you suggesting to change this behaviour/ > HINT: NULL

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-22 20:15 GMT+02:00 Jim Nasby : > On 10/22/15 2:20 AM, dinesh kumar wrote: > >> >> 2. Using this function, if we provide any "NULL" argument to the function, >> we should either skip it or report it. I see this is what the function >> is doing. >> >> postgres=#

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-23 0:07 GMT+02:00 Jim Nasby : > On 10/22/15 4:59 PM, Pavel Stehule wrote: > >> It prevents everyone from reinventing the 'create a function wrapper >> around RAISE' wheel that several people on this list alone have >> admitted to. I think there's

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/22/15 4:42 PM, Pavel Stehule wrote: the behave of pg_report_log should not be exactly same as RAISE statement in PLpgSQL. That makes no sense to me. Having different behaviors is just going to lead to confusion. If this function will be exactly same, then it lost a sense and anybody

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-22 23:54 GMT+02:00 Jim Nasby : > On 10/22/15 4:42 PM, Pavel Stehule wrote: > >> the behave of pg_report_log should not be exactly same as RAISE >> statement in PLpgSQL. >> > > That makes no sense to me. Having different behaviors is just going to > lead to

Re: [HACKERS] [PATCH] SQL function to report log message

Hi 2015-10-22 22:03 GMT+02:00 Peter Eisentraut : > On 10/22/15 3:20 AM, dinesh kumar wrote: > > postgres=# SELECT pg_report_log('INFO', 'NULL', false, NULL, NULL); > > INFO: NULL > > > > postgres=# SELECT pg_report_log('INFO', 'NULL', false, 'NULL', 'NULL'); > > INFO: NULL > >

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/22/15 4:59 PM, Pavel Stehule wrote: It prevents everyone from reinventing the 'create a function wrapper around RAISE' wheel that several people on this list alone have admitted to. I think there's plenty of value in that. I have different opinion, I am sorry. The RAISE

Re: [HACKERS] [PATCH] SQL function to report log message

On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule wrote: > 2015-10-20 17:15 GMT+02:00 Robert Haas : >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule >> wrote: >> > Probably it was my request. I don't like to using NULL as

Re: [HACKERS] [PATCH] SQL function to report log message

On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule wrote: > Probably it was my request. I don't like to using NULL as value, that should > be ignored. The "hint" is clean, there NULL can be ignored, but what about > DETAIL or MESSAGE? If the field is required - as MESSAGE

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-20 17:15 GMT+02:00 Robert Haas : > On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule > wrote: > > Probably it was my request. I don't like to using NULL as value, that > should > > be ignored. The "hint" is clean, there NULL can be ignored,

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-20 20:05 GMT+02:00 Robert Haas : > On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule > wrote: > > 2015-10-20 17:15 GMT+02:00 Robert Haas : > >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule < >

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Oct 19, 2015 at 7:59 PM, Jim Nasby wrote: > I fail to see how doing > > HINT: NULL > > is much better than just not raising a HINT at all... I'm not a huge fan of this patch, as previously noted, but I certainly agree that if we're going to do it, we should

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-20 16:50 GMT+02:00 Robert Haas : > On Mon, Oct 19, 2015 at 7:59 PM, Jim Nasby > wrote: > > I fail to see how doing > > > > HINT: NULL > > > > is much better than just not raising a HINT at all... > > I'm not a huge fan of this patch, as

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-18 21:13 GMT+02:00 Jim Nasby : > On 10/17/15 11:49 AM, Pavel Stehule wrote: > >> 2015-10-17 18:42 GMT+02:00 Jim Nasby > >: >> >> On 10/15/15 11:51 PM, Pavel Stehule wrote: >> >> I don't think

Re: [HACKERS] [PATCH] SQL function to report log message

Hi 2015-10-13 22:01 GMT+02:00 Robert Haas : > This patch is marked as Ready for Committer in the CommitFest > application. Here is my attempt to summarize the votes upthread: > > Tom Lane: plpgsql RAISE is sufficient; we don't need this. > Pavel Stehule: could be replaced

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/19/15 1:09 AM, Pavel Stehule wrote: What I was trying to say is that if the argument to a USING option is NULL then RAISE should skip over it, as if it hadn't been applied at all. Similar to how the code currently tests for \0.

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/17/15 11:49 AM, Pavel Stehule wrote: 2015-10-17 18:42 GMT+02:00 Jim Nasby >: On 10/15/15 11:51 PM, Pavel Stehule wrote: I don't think so ignoring NULL in RAISE statement is good idea (it is not safe).

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/15/15 11:51 PM, Pavel Stehule wrote: I don't think so ignoring NULL in RAISE statement is good idea (it is not safe). We can replace NULL by some string (like "NULL") by default. I am thinking about other possibilities. What I was trying to say is that if the argument to a USING option

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-17 18:42 GMT+02:00 Jim Nasby : > On 10/15/15 11:51 PM, Pavel Stehule wrote: > >> I don't think so ignoring NULL in RAISE statement is good idea (it is >> not safe). We can replace NULL by some string (like "NULL") by default. >> I am thinking about other

Re: [HACKERS] [PATCH] SQL function to report log message

On 9/10/15 10:56 AM, Andres Freund wrote: >The only complaint I've seen in this thread that seems like a valid >deficiency is that RAISE can't deal with treating the error severity level >as a variable. But surely we should address that as a new RAISE feature, >not by inventing a SQL wrapper

Re: [HACKERS] [PATCH] SQL function to report log message

On 14 October 2015 at 04:01, Robert Haas wrote: > This patch is marked as Ready for Committer in the CommitFest > application. Here is my attempt to summarize the votes upthread: > > Tom Lane: plpgsql RAISE is sufficient; we don't need this. > Pavel Stehule: could be

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-16 2:47 GMT+02:00 Jim Nasby : > On 9/10/15 10:56 AM, Andres Freund wrote: > >> >The only complaint I've seen in this thread that seems like a valid >>> >deficiency is that RAISE can't deal with treating the error severity >>> level >>> >as a variable. But surely

Re: [HACKERS] [PATCH] SQL function to report log message

This patch is marked as Ready for Committer in the CommitFest application. Here is my attempt to summarize the votes upthread: Tom Lane: plpgsql RAISE is sufficient; we don't need this. Pavel Stehule: could be replaced by custom function, but not against it. Robert Haas: plpgsql RAISE is

Re: [HACKERS] [PATCH] SQL function to report log message

Hi All, Thanks for your inputs on this. Here, I see a conflict between the doable{RAISE}, and convenience{SQL function}, and will follow your inputs on this. Also, I was under impression that, all our TODO items are filtered for the real use cases. Is my

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Sep 10, 2015 at 8:44 PM, Alvaro Herrera wrote: > dinesh kumar wrote: > > > Also, I was under impression that, all our TODO > > items are filtered for the real > use > > cases. Is my impression wrong. If I wanted to work on

Re: [HACKERS] [PATCH] SQL function to report log message

dinesh kumar wrote: > Also, I was under impression that, all our TODO > items are filtered for the real use > cases. Is my impression wrong. If I wanted to work on another TODO item, > where i need to take a look. Your impression is completely, absolutely,

Re: [HACKERS] [PATCH] SQL function to report log message

On 2015-09-09 23:45:08 -0400, Tom Lane wrote: > Were all twenty of them exactly alike? Were they identical to Andres' > several dozen attempts? Mine were pretty much alike and trivial - which is why I never even bothered to standardize on a variant and store it somewhere. > The problem I've got

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Sep 10, 2015 at 8:14 AM, Alvaro Herrera wrote: > dinesh kumar wrote: > > > Also, I was under impression that, all our TODO > > items are filtered for the real > use > > cases. Is my impression wrong. If I wanted to work on

Re: [HACKERS] [PATCH] SQL function to report log message

On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar wrote: >> The real question is why the existing functionality in plpgsql isn't >> sufficient. Somebody who wants a "log from SQL" function can easily >> write a simple plpgsql function that does exactly what they want, >>

Re: [HACKERS] [PATCH] SQL function to report log message

HI Robert, On Wed, Sep 9, 2015 at 8:30 PM, Robert Haas wrote: > On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar > wrote: > >> The real question is why the existing functionality in plpgsql isn't > >> sufficient. Somebody who wants a "log from SQL"

Re: [HACKERS] [PATCH] SQL function to report log message

On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar wrote: > I am admitting here that, I don’t know the real use case behind this > proposal in our TODO list. I thought, having ereport wrapper at SQL level, > gives a default debugging behavior for the end users, and this is the

Re: [HACKERS] [PATCH] SQL function to report log message

On 9/9/15 5:27 PM, Robert Haas wrote: Sure, it’s a clear fact that, we can implement this function with RAISE >statements. Given that, I suggest we just forget the whole thing. Except that you can't use a variable to control the log level in a plpgsql RAISE, so then you end up with a CASE

Re: [HACKERS] [PATCH] SQL function to report log message

On 2015-09-09 18:27:51 -0400, Robert Haas wrote: > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar wrote: > > Sure, it’s a clear fact that, we can implement this function with RAISE > > statements. > > Given that, I suggest we just forget the whole thing. I'm not

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote: > On 2015-09-09 18:27:51 -0400, Robert Haas wrote: > > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar > > wrote: > > > Sure, it’s a clear fact that, we can implement this function > > > with RAISE statements.

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-10 2:47 GMT+02:00 David Fetter : > On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote: > > On 2015-09-09 18:27:51 -0400, Robert Haas wrote: > > > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar > wrote: > > > > Sure, it’s a clear fact

Re: [HACKERS] [PATCH] SQL function to report log message

David Fetter writes: > On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote: >> I'm not convinced. Sure, it's easy, but I by now have written the >> respective function dozens of times. Why should we force that on >> everyone? > +20 or so here, that being the number of

Re: [HACKERS] [PATCH] SQL function to report log message

On Sun, Sep 6, 2015 at 4:00 PM, dinesh kumar wrote: > On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule > wrote: > >> Hi >> >> attached patch with fixed broken error message >> >> Regards >> >> Pavel >> > > Hi Pavel, > > Thanks much for taking care

Re: [HACKERS] [PATCH] SQL function to report log message

Hi attached patch with fixed broken error message Regards Pavel diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index b3b78d2..b7a2cc2 *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** postgres=# SELECT * FROM pg_xlogfile_nam ***

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-06 13:12 GMT+02:00 dinesh kumar : > > On Sun, Sep 6, 2015 at 4:00 PM, dinesh kumar > wrote: > >> On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule >> wrote: >> >>> Hi >>> >>> attached patch with fixed broken error

Re: [HACKERS] [PATCH] SQL function to report log message

Hi I am sending little bit modified version. 1. sqlstate should be text, not boolean - a boolean is pretty useless 3. fixed formatting and code style Questions: I dislike the using empty message when message parameter is null. We have to show some text or we have to disallow it? Regards

Re: [HACKERS] [PATCH] SQL function to report log message

On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule wrote: > Hi > > attached patch with fixed broken error message > > Regards > > Pavel > Hi Pavel, Thanks much for taking care of it. Patch looks great. -- Regards, Dinesh manojadinesh.blogspot.com

Re: [HACKERS] [PATCH] SQL function to report log message

On Sun, Sep 6, 2015 at 4:46 PM, Pavel Stehule wrote: > > > 2015-09-06 13:12 GMT+02:00 dinesh kumar : > >> >> On Sun, Sep 6, 2015 at 4:00 PM, dinesh kumar >> wrote: >> >>> On Sun, Sep 6, 2015 at 3:39 PM, Pavel Stehule

Re: [HACKERS] [PATCH] SQL function to report log message

On Fri, Sep 4, 2015 at 2:03 PM, Pavel Stehule wrote: > > > 2015-09-02 21:49 GMT+02:00 dinesh kumar : > >> On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule >> wrote: >> >>> >>> >>> 2015-09-01 6:59 GMT+02:00 Pavel Stehule

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-05 8:35 GMT+02:00 dinesh kumar : > > > On Fri, Sep 4, 2015 at 2:03 PM, Pavel Stehule > wrote: > >> >> >> 2015-09-02 21:49 GMT+02:00 dinesh kumar : >> >>> On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule

Re: [HACKERS] [PATCH] SQL function to report log message

Hi Pavel, On Sat, Sep 5, 2015 at 12:36 AM, Pavel Stehule wrote: > > > 2015-09-05 8:35 GMT+02:00 dinesh kumar : > >> >> >> On Fri, Sep 4, 2015 at 2:03 PM, Pavel Stehule >> wrote: >> >>> >>> >>> 2015-09-02 21:49 GMT+02:00

Re: [HACKERS] [PATCH] SQL function to report log message

On Fri, Sep 4, 2015 at 1:08 PM, Pavel Stehule wrote: > > > 2015-09-02 21:49 GMT+02:00 dinesh kumar : > >> On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule >> wrote: >> >>> >>> >>> 2015-09-01 6:59 GMT+02:00 Pavel Stehule

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-02 21:49 GMT+02:00 dinesh kumar : > On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule > wrote: > >> >> >> 2015-09-01 6:59 GMT+02:00 Pavel Stehule : >> >>> >>> >>> 2015-08-31 20:43 GMT+02:00 dinesh kumar

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-02 21:49 GMT+02:00 dinesh kumar : > On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule > wrote: > >> >> >> 2015-09-01 6:59 GMT+02:00 Pavel Stehule : >> >>> >>> >>> 2015-08-31 20:43 GMT+02:00 dinesh kumar

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule wrote: > > > 2015-09-01 6:59 GMT+02:00 Pavel Stehule : > >> >> >> 2015-08-31 20:43 GMT+02:00 dinesh kumar : >> >>> Hi, >>> >>> On Sat, Aug 29, 2015 at 4:22 PM, Pavel Stehule

Re: [HACKERS] [PATCH] SQL function to report log message

On Tue, Sep 1, 2015 at 6:13 PM, Jim Nasby wrote: > My thought is that there's a fair amount of places where we do string > comparison for not a great reason. Perhaps a better example is data that > comes back from a trigger; AFTER/BEFORE, INSERT/UPDATE/..., which is more

Re: [HACKERS] [PATCH] SQL function to report log message

On 9/1/15 12:47 AM, Pavel Stehule wrote: Wouldn't it be better to create an ENUM of error levels instead of inventing more parsing code? Do you think SQL ENUM? I little bit afraid about possible problems with pg_upgrade. It is not simple question - the ENUM can be interesting from

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-02 0:13 GMT+02:00 Jim Nasby : > On 9/1/15 12:47 AM, Pavel Stehule wrote: > >> >> Wouldn't it be better to create an ENUM of error levels instead of >> inventing more parsing code? >> >> >> Do you think SQL ENUM? I little bit afraid about possible problems

Re: [HACKERS] [PATCH] SQL function to report log message

Hi, On Sat, Aug 29, 2015 at 4:22 PM, Pavel Stehule wrote: > Hi > > I am starting to work review of this patch > > 2015-07-13 9:54 GMT+02:00 dinesh kumar : > >> Hi All, >> >> Greetings for the day. >> >> Would like to discuss on below feature

Re: [HACKERS] [PATCH] SQL function to report log message

2015-08-31 20:43 GMT+02:00 dinesh kumar : > Hi, > > On Sat, Aug 29, 2015 at 4:22 PM, Pavel Stehule > wrote: > >> Hi >> >> I am starting to work review of this patch >> >> 2015-07-13 9:54 GMT+02:00 dinesh kumar : >> >>> Hi

Re: [HACKERS] [PATCH] SQL function to report log message

On 8/31/15 11:59 PM, Pavel Stehule wrote: The transformation: text -> error level is common task - and PLpgSQL it does in pl_gram.y. My idea is to add new function to error utils named "parse_error_level" and use it from PLpgSQL and from your code. Wouldn't it be better to create an ENUM of

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-01 6:59 GMT+02:00 Pavel Stehule : > > > 2015-08-31 20:43 GMT+02:00 dinesh kumar : > >> Hi, >> >> On Sat, Aug 29, 2015 at 4:22 PM, Pavel Stehule >> wrote: >> >>> Hi >>> >>> I am starting to work review of this

Re: [HACKERS] [PATCH] SQL function to report log message

2015-09-01 7:20 GMT+02:00 Jim Nasby : > On 8/31/15 11:59 PM, Pavel Stehule wrote: > >> The transformation: text -> error level is common task - and PLpgSQL it >> does in pl_gram.y. My idea is to add new function to error utils named >> "parse_error_level" and use it from

Re: [HACKERS] [PATCH] SQL function to report log message

On Sun, Aug 30, 2015 at 4:52 AM, Pavel Stehule pavel.steh...@gmail.com wrote: Hi I am starting to work review of this patch Hi Pavel, Thanks for your review. 2015-07-13 9:54 GMT+02:00 dinesh kumar dineshkuma...@gmail.com: Hi All, Greetings for the day. Would like to discuss on

Re: [HACKERS] [PATCH] SQL function to report log message

Hi I am starting to work review of this patch 2015-07-13 9:54 GMT+02:00 dinesh kumar dineshkuma...@gmail.com: Hi All, Greetings for the day. Would like to discuss on below feature here. Feature: Having an SQL function, to write messages to log destination. Justification: As

Re: [HACKERS] [PATCH] SQL function to report log message

Hi All, On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jim Nasby jim.na...@bluetreble.com writes: On 7/13/15 3:39 PM, dinesh kumar wrote: Ah. It's' my bad interpretation. Let me work on it, and will send a new patch as a wrapper sql function for ereport. You might

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Jul 23, 2015 at 10:56 AM, dinesh kumar dineshkuma...@gmail.com wrote: Hi All, On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jim Nasby jim.na...@bluetreble.com writes: On 7/13/15 3:39 PM, dinesh kumar wrote: Ah. It's' my bad interpretation. Let me work on it,

Re: [HACKERS] [PATCH] SQL function to report log message

On Wed, Jul 22, 2015 at 8:56 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Thu, Jul 23, 2015 at 10:56 AM, dinesh kumar dineshkuma...@gmail.com wrote: Hi All, On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jim Nasby jim.na...@bluetreble.com writes: On

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:11 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Mon, Jul 13, 2015 at 4:54 PM, dinesh kumar dineshkuma...@gmail.com wrote: Would like to discuss on below feature here. Feature: Having an SQL function, to write messages to log destination.

Re: [HACKERS] [PATCH] SQL function to report log message

On 7/13/15 3:39 PM, dinesh kumar wrote: I don't really see the point of what you're describing here. Just do something like RAISE WARNING which should normally be high enough to make it into the logs. Or use a pl language that will let you write your own logfile on the server

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:56 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 7/13/15 3:39 PM, dinesh kumar wrote: I don't really see the point of what you're describing here. Just do something like RAISE WARNING which should normally be high enough to make it into the logs. Or

Re: [HACKERS] [PATCH] SQL function to report log message

Jim Nasby jim.na...@bluetreble.com writes: On 7/13/15 3:39 PM, dinesh kumar wrote: Ah. It's' my bad interpretation. Let me work on it, and will send a new patch as a wrapper sql function for ereport. You might want to present a plan for that; it's not as trivial as it sounds due to how

Re: [HACKERS] [PATCH] SQL function to report log message

On 7/13/15 12:39 PM, dinesh kumar wrote: As of now, we don't have an SQL function to write custom/application messages to log destination. We have RAISE clause which is controlled by log_ parameters. If we have an SQL function which works irrespective of log settings,

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:29 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 7/13/15 12:39 PM, dinesh kumar wrote: As of now, we don't have an SQL function to write custom/application messages to log destination. We have RAISE clause which is controlled by log_

[HACKERS] [PATCH] SQL function to report log message

Hi All, Greetings for the day. Would like to discuss on below feature here. Feature: Having an SQL function, to write messages to log destination. Justification: As of now, we don't have an SQL function to write custom/application messages to log destination. We have RAISE clause which

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 4:54 PM, dinesh kumar dineshkuma...@gmail.com wrote: Would like to discuss on below feature here. Feature: Having an SQL function, to write messages to log destination. Justification: As of now, we don't have an SQL function to write custom/application