HI Robert, On Wed, Sep 9, 2015 at 8:30 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar <dineshkuma...@gmail.com> > 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-whistles than they need. If we try > >> to create a SQL function that does all that, it's likely to be a mess > >> to use, even with named arguments. > >> > >> I'm not necessarily against the basic idea, but I think inventing > >> something that actually offers an increment in usability compared > >> to the existing alternative is going to be harder than it sounds. > >> > > > > I agree with your inputs. We can build pl/pgsql function as alternative > for > > this. > > > > My initial proposal, and implementation was, logging messages to log file > > irrespectively of our log settings. I was not sure we can do this with > some > > pl/perlu. And then, I started working on our to do item, > > ereport, wrapper callable from SQL, and found it can be useful to have a > > direct function call with required log level. > > But, why? > > 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 see. > I just took a look at the latest patch and I can't see why it's any > better than just using PL/pgsql's RAISE statement. > > Sure, it’s a clear fact that, we can implement this function with RAISE statements. Thanks in advance for your guidance. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Regards, Dinesh manojadinesh.blogspot.com
