| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> | 
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> | 
| Cc: | dinesh kumar <dineshkumar02(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [PATCH] SQL function to report log message | 
| Date: | 2015-09-01 05:47:12 | 
| Message-ID: | CAFj8pRBcD2vgq-V1SSdfPw-0r8zTsP_Dy0ismnsniXsPG7ZECA@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
2015-09-01 7:20 GMT+02:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:
> 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 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 custom space
perspective, but from our internal perspective the parsing function is more
practical - and faster. The error level is our internal value, and users
should not to read it - for this purpouse is error level.
>
> Though, I guess ENUMs are case sensitive, but I'd rather solve that by
> creating a CI ENUM, which would be useful across the board...
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2015-09-01 06:08:20 | Re: Fwd: Core dump with nested CREATE TEMP TABLE | 
| Previous Message | Pavel Stehule | 2015-09-01 05:40:01 | Re: On-demand running query plans using auto_explain and signals |