Andrew Dunstan <and...@dunslane.net> wrote: > Have you performance tested it? Scanning pg_index for index > columns for each row strikes me as likely to be unpleasant. I haven't, yet. I had rather assumed that the index info for a relation would have a high probability of being cached during execution of an AFTER trigger for that relation, so I think we're talking RAM access here. It didn't seem sane to try to create an HTAB for this and worry about invalidation of it, etc. If there's a faster way to get to the info without going to such extremes, I'd be happy to hear them. (At least I avoided building and parsing a query to get at it.) > Also, the error messages seem to need a bit of work (no wonder > they seemed familiar to me :) ) [blush] I was just trying to write code with "fits in with surrounding code", as recommended. You mean I should change the function name in the message from the name of the function I copied *from* to the name of the function I copied *to*? Well, I *guess* it still fits in.... ;-) Seriously, thanks for pointing that out. Will fix. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
