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: | Raw Message | Whole Thread | 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 |