Re: [PATCH] SQL function to report log message

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [PATCH] SQL function to report log message
Дата
Msg-id CAFj8pRBcD2vgq-V1SSdfPw-0r8zTsP_Dy0ismnsniXsPG7ZECA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] SQL function to report log message  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [PATCH] SQL function to report log message  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers


2015-09-01 7:20 GMT+02:00 Jim Nasby <Jim.Nasby@bluetreble.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: On-demand running query plans using auto_explain and signals
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Fwd: Core dump with nested CREATE TEMP TABLE