Q: pg_catalog views, OIDs and search_path

Поиск
Список
Период
Сортировка
От Ian Barwick
Тема Q: pg_catalog views, OIDs and search_path
Дата
Msg-id 200302172344.45315.barwick@gmx.net
обсуждение исходный текст
Ответы Re: Q: pg_catalog views, OIDs and search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Version 7.2.3 Vacuum abnormality
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COUNT and Performance ...