2015-09-02 0:13 GMT+02:00 Jim Nasby <jim.na...@bluetreble.com>: > 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.
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 >
