On Wednesday 19 May 2010 04:52:20 am Christoph Gohle wrote: > Dear John, > > sorry for not replying to your message directly, but somehow I am > unable to subscribe to the list and therefore don't recieve any > messages... (!) > > the documentation on pg_table_is_visible can be found here > > http://www.postgresql.org/docs/8.1/interactive/functions-info.html#FUNCTION >S-INFO-SCHEMA-TABLE > > and the header to this table reads: > > QUOTE > Table 9-41 shows functions that determine whether a certain object is > visible in the current schema search path. A table is said to be > visible if its containing schema is in the search path and no table of > the same name appears earlier in the search path. This is equivalent > to the statement that the table can be referenced by name without > explicit schema qualification. > \QUOTE > > To my understanding this has nothing to do with security. Access to > the tables inside a schema are granted separately by "GRANT/REVOKE sth > ON SCHEMA xy TO/FROM user" statements according to the doc you have > sent to me. Opposed to that 'pg_table_is_visible' only checks if a > table with name 'table' is on the search path, meaning it can be > referenced without using the 'schema.table' syntax. > > Let me know if you see this differently. I will check back to the > archives regularily until I can fix the problem with subscription. > > Kind regards, > Christoph.
Maybe security is the wrong word - although it's not to far off. Imagine that I have several schemas within a single database - api, public, and dev. Now what I want is for my Dabo users to have access to only two of them from maybe ReportDesigner. IOW's I don't want them to see 'dev' because I repeated the table names from the other schemas or for some other reason. I could insure that all my users have privileges for only api and public and I could just remove the schema from the seach path. A sort out of sight out of mind kind of thing. So not only do permissions come in to play but also the search path does too. In general this is how it was explained to me. The section of the postgres doc's explains it a bit better than I have. Now that I have said the above there was a very practial reason too. At one time Dabo did not support schema's as well as it does today. So using the search path helped allow Dabo to use just table names and not require the full syntax of database.schema.table. And to be honest, I don't know that Dabo has all the schemas rules down pat because I haven't really tested. Is there a reason you can't change your search path? Or is it you just feel it should not be a requirement to do so? 5.7.3. The Schema Search Path Qualified names are tedious to write, and it's often best not to wire a particular schema name into applications anyway. Therefore tables are often referred to by unqualified names, which consist of just the table name. The system determines which table is meant by following a search path, which is a list of schemas to look in. The first matching table in the search path is taken to be the one wanted. If there is no match in the search path, an error is reported, even if matching table names exist in other schemas in the database. The first schema named in the search path is called the current schema. Aside from being the first schema searched, it is also the schema in which new tables will be created if the CREATE TABLE command does not specify a schema name. Johnf _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[email protected]
