Re: [HACKERS] Q: pg_catalog views, OIDs and search_path

[Tom Lane]

Ian Barwick <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

[HACKERS] 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 the backend 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
[EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org