Re: missing toast table for pg_policy

On 2018-02-17 11:39:57 -0500, Tom Lane wrote:
> BTW, I was wondering if it'd be a good idea to try to forestall future
> oversights of this sort by adding a test query in, say, misc_sanity.sql.
> Something like

+many


>          relname         |     attname     |   atttypid   
> -------------------------+-----------------+--------------
>  pg_aggregate            | agginitval      | text
>  pg_aggregate            | aggminitval     | text

Seems like it should have a toast table, it's not too hard to imagine
some form of aggregate to have a large initial condition.


>  pg_attribute            | attacl          | aclitem[]
>  pg_attribute            | attfdwoptions   | text[]
>  pg_attribute            | attoptions      | text[]

Seems like it should have a toast table, but I think other people
differed.


>  pg_authid               | rolpassword     | text

that seems not not to require one.


>  pg_class                | relacl          | aclitem[]
>  pg_class                | reloptions      | text[]
>  pg_class                | relpartbound    | pg_node_tree

I still think this should have one, but we disagreed. Only argument
against that I can see is complexity around rewrites.


>  pg_collation            | collversion     | text

unnecessary.


>  pg_database             | datacl          | aclitem[]
>  pg_default_acl          | defaclacl       | aclitem[]

hm.

>  pg_event_trigger        | evttags         | text[]

unnecessary?


>  pg_extension            | extcondition    | text[]
>  pg_extension            | extconfig       | oid[]
>  pg_extension            | extversion      | text

Possibly add?


>  pg_foreign_data_wrapper | fdwacl          | aclitem[]
>  pg_foreign_data_wrapper | fdwoptions      | text[]

Possibly add?


>  pg_foreign_server       | srvacl          | aclitem[]
>  pg_foreign_server       | srvoptions      | text[]
>  pg_foreign_server       | srvtype         | text
>  pg_foreign_server       | srvversion      | text
>  pg_foreign_table        | ftoptions       | text[]

Add? That's a fair number of potentially longer fields.


>  pg_index                | indexprs        | pg_node_tree
>  pg_index                | indpred         | pg_node_tree

Imo we should add one here, but honestly I can recall only one or two
complaints.


>  pg_init_privs           | initprivs       | aclitem[]

Only if we decide to make other aclitem containing fields toastable.


>  pg_largeobject          | data            | bytea

We deal with this in other ways.


>  pg_partitioned_table    | partexprs       | pg_node_tree

Probably makes sense.


>  pg_pltemplate           | tmplacl         | aclitem[]
>  pg_pltemplate           | tmplhandler     | text
>  pg_pltemplate           | tmplinline      | text
>  pg_pltemplate           | tmpllibrary     | text
>  pg_pltemplate           | tmplvalidator   | text

Hard to imagine this being required, unless we just want to make
aclitem[] toastable as a rule.


>  pg_policy               | polqual         | pg_node_tree
>  pg_policy               | polroles        | oid[]
>  pg_policy               | polwithcheck    | pg_node_tree

Yes.


>  pg_replication_origin   | roname          | text

unnecessary.


>  pg_subscription         | subconninfo     | text
>  pg_subscription         | subpublications | text[]
>  pg_subscription         | subsynccommit   | text

I'd say yes, with a few alternative hosts connection info can become
quite long.


>  pg_tablespace           | spcacl          | aclitem[]
>  pg_tablespace           | spcoptions      | text[]

Hm?


>  pg_ts_dict              | dictinitoption  | text

probably not.


> I think in most of these cases we've consciously decided not to toast-ify,
> but maybe some of them need a second look.

Greetings,

Andres Freund