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 plpgsql? (The func

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 coalesce if you want the string 'NULL'; I

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 s

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 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 majority of users will

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 omitted. > I think th

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 a better name to me

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 with > > others here that the vast majority

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 omitted. +1 Unfortunately tho

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]) > > + > > + void >

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 this functionality.

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

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 plenty of value in that. >> >>

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 statem

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 confusion. > > If this function w

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=# SELECT pg_report_log('INFO'

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 c

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 > > DETAIL: NULL /-

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 Th

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. >> >> postgres=# SELECT pg_repo

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=# SELE

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 : >> >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule < >> pavel.steh...@gmail.

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 < > pavel.steh...@gmail.com> > >> wrote: > >> > Probably it was my request. I don't like to using N

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 value, that >> > should >> > be ignored. The "hint" is clean, there NULL ca

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, but what > about > > DETAIL or MESSAGE? > > If the

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 is - then its absence is an

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 previously noted, but I certainly > agree that if we

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 ignore a null argument, not pri

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

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 by custom function, but

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 so ignoring NULL in RAISE statement is good idea >>

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 mailto:jim.na...@bluetreble.com>>: 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

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 possibilities. >> > > What I was tr

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 is

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 replaced by custom function,

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 we should address that as

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 tha

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 sufficie

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 another TODO item, > > whe

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: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 another TODO item, > > whe

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

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 i

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 times I recall off

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 that, we can implement this function > > > >

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. > > > > Given that, I sug

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 convinced. Sure, it's easy, but I

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 sta

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 only > real use case I se

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" function can easily > >> write a simple plpgsql

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, >> with no more or fewer bells-n

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 >>> wrote: >>> Hi attached patch with fixed broken error messag

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 message >>> >>> Regards >>> >>> Pavel >>> >> >> Hi Pavel, >> >> Thanks much fo

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 of it. Patch looks great. > > > Hi Pavel, Could yo

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

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 *** 17925,17

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 Pavel

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 dinesh kumar : >>> On Mon, Aug 31, 2015 at 10:08 PM, 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 >> > wrote: >>> 2015-09-01 6:59 GMT+02:00 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 : >>> 2015-08-31 20:43 GMT+02:00 dinesh kumar : > Hi,

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 : >>> 2015-08-31 20:43 GMT+02:00 dinesh kumar : > Hi,

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 : >>> Hi, On Sat, Aug 29, 2015 at 4:22 PM, Pavel Stehule >>> > wrote: >>>

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 : >>> Hi, On Sat, Aug 29, 2015 at 4:22 PM, Pavel Stehule >>> > wrote: >>>

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 >>> wrote: >>> Hi I am starting to work review of this patc

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 > expensive to setup the v

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 with >> pg_upgrade. >> >>

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 cus

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 PLpgSQL and from your code

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 err

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 patch >>> >>> 2015-07-13 9:54 GMT+02:00 dinesh kumar : >>> Hi All, >>>

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 All, >>> >>> Greetings for the day. >>> >>> Would like to discuss on below

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 here. >> >> Feature: >> Having an SQL function, to

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

On Sun, Aug 30, 2015 at 4:52 AM, Pavel Stehule 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 : > >> Hi All, >> >> Greetings for the day. >> >> Would like to discuss on below feature here. >> >> Feature:

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 : > 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

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

On Wed, Jul 22, 2015 at 8:56 PM, Michael Paquier wrote: > On Thu, Jul 23, 2015 at 10:56 AM, dinesh kumar > wrote: > > Hi All, > > > > On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane wrote: > >> > >> Jim Nasby writes: > >> > On 7/13/15 3:39 PM, dinesh kumar wrote: > >> >> Ah. It's' my bad interpretat

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

On Thu, Jul 23, 2015 at 10:56 AM, dinesh kumar wrote: > Hi All, > > On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane wrote: >> >> Jim Nasby 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 fun

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

Hi All, On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane wrote: > Jim Nasby 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

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

Jim Nasby 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 ereport works. In part

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

On Mon, Jul 13, 2015 at 1:56 PM, Jim Nasby 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 use a pl language

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 (ie:

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

On Mon, Jul 13, 2015 at 1:29 PM, Jim Nasby 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_ parameters. If w

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 > setting

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

On Mon, Jul 13, 2015 at 1:11 AM, Michael Paquier wrote: > On Mon, Jul 13, 2015 at 4:54 PM, dinesh kumar > 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 do

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

On Mon, Jul 13, 2015 at 4:54 PM, dinesh kumar 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 > messages to log desti

[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 whic