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.
What I know, we currently don't use ENUM in core code. One reason can be missing infrastructure - second increasing complexity for development - the using ENUM needs database cleaning or initdb currently. There is lot of work to get ENUM to state be developer friendly. I am don't think so this is a area for this patch, this thread. If we use shared parsing of elog levels, then we don't block future changes in this area.
Regards
Pavel
-- 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
