KaiGai Kohei <kaigai@kaigai.gr.jp> writes:
> I didn't replace the previous implementation blindly, I have a few
> reasons that the current one is better than previous one.
>
> For example, if an input handler has side-effects, what is happen in
> the following query?
>
> SELECT 'valid_but_new_security_label'::regseclabel;
>
> It looks like a read-only query, but the input handler can insert a new
> tuple into pg_security. In addition, the newly inserted tuple may not
> be refered any more. It is a waste of spaces.
Ooh, and how would we know when to vacuum this label?
In the case of toast each external attribute is owned by precisely one record
(though possibly multiple versions of it). So when the record is deleted or
the attribute replaced we mark the toasted attribute's xmax and it can be
vacuumed later.
In this case you have pg_security attributes shared by many records. So we
have no way to know when they're no longer referenced.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
