KaiGai Kohei wrote: >> Can we support two data types, one for read-only and another for >> possible creation? That is not going to work for a query like >> >> SELECT * FROM x WHERE col != >> 'valid_but_new_security_label'::regseclabel; >> >> because the cast would fail if the pg_security row doesn't exist, but >> the query itself perhaps might succeed and return rows. > > It has a same matter. If user cast a text into the type of possible > creation, it can cause an unnecessary insertion.
How's this for an idea. Keep a cache in memory, which has a reference counter. This counter would only be incremented for written tuples. At transaction end (or when the cache is full and you need more room), entries are evicted; if the reference count is greater than zero on eviction, a pg_security entry is created. Otherwise it is just discarded. pg_security entry creation (i.e. eviction from cache, or at transaction end) is WAL-logged, which is enough in case of a crash, because if a tuple is written with an unlogged pg_security OID, the transaction did not abort and thus nobody can possibly be interested in translating it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
