Re: [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 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.

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 variables for (strdup a fixed string, which means a palloc), and then comparisons are done as text varlena (iirc).

Instead if this information came back as an ENUM the variable would be a simple int as would the comparison. We'd still have a raw string being parsed in the function body, but that would happen once during initial compilation and it would be replaced with an ENUM value.

For RAISE, AFAIK we still end up converting the raw string into a varlena CONST, which means a palloc. If it was an ENUM it'd be converted to an int.

If we're worried about the overhead of the enum machinery we could create a relcache for system enums, but I suspect that even without that it'd be a win over the string stuff. Especially since I bet most people run UTF8.

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