Обсуждение: Q: pg_catalog views, OIDs and search_path

Поиск
Список
Период
Сортировка

Q: pg_catalog views, OIDs and search_path

От
Ian Barwick
Дата:
I'm preparing a patch to make more psql slash commands
tab-completable (\di, \dv etc-) and have come across the following dilemma:

- only relations visible in the current search path should be returned [*]
- to determine visibilty via pg_catalog.pg_table_is_visible(), the  relation's OID is necessary;
- using (say) pg_catalog.pg_views to obtain view names seems to be the "cleaner" approach (making psql independent from
thebackend etc.) 
- views don't come with OIDs

As is psql currently uses pg_catalog.pg_views to complete view names,
meaning it will happily tab-complete (say) DROP VIEW with a view _not_
in the current search path. If executed the statement naturally
produces the error 'ERROR: view "..." does not exist'.

Q: is there any likelihood of the pg_catalog views (pg_views, pg_tables,  pg_indexes, pg_rules, possibly others I have
missed)returning the   relevant OID or (probably cleaner) the result of pg_table_is_visible()   as a boolean? 

Otherwise the only workaround will be to ignore the catalog views and
work with pg_class directly, which I will probably do, but it
feels like a step backwards.

[*] at least, this is how \d currently behaves and IMHO is intuitive.   \d should of course operate on schema names
too,to enable   completion of relation names not in the search path; tentative   patch will follow. 


Ian Barwick
barwick@gmx.net



Re: Q: pg_catalog views, OIDs and search_path

От
Tom Lane
Дата:
Ian Barwick <barwick@gmx.net> writes:
> Q: is there any likelihood of the pg_catalog views (pg_views, pg_tables,
>    pg_indexes, pg_rules, possibly others I have missed) returning the 
>    relevant OID or (probably cleaner) the result of pg_table_is_visible() 
>    as a boolean?

That strikes me as awfully ugly --- the apparent contents of the view
would change depending on your search_path setting.  Which seems weird.

> Otherwise the only workaround will be to ignore the catalog views and
> work with pg_class directly, which I will probably do, but it
> feels like a step backwards.

I don't see a problem with it.  The only thing those views really do for
you is keep you from having to know the character codes for relkind,
which is not a lot of implementation-dependence compared to all the
other stuff that \d knows ...
        regards, tom lane