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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
