Re: getTables or code problem?

Kris,

I agree with your thoughts:  return no rows for other catalogs, and have
getCatalogs only return the current one you are connected to.  While
this is limiting, it will provide the best (but certainly not ideal)
user experience with tools like DBVisualizer.

--Barry

Kris Jurka wrote:
>
> On Fri, 16 Jan 2004, Alessandro Depase wrote:
>
>
>>>The way the postgresql server works is that you can only connect to one
>>>database at a time.  This means that is impossible to list the tables in a
>>>database that you are not connected to.  The thing is that you can get a
>>>list of all the databases from any database because pg_database is a
>>>global table.  It has been debated here before whether we should return
>>>only the database you are connected to in the results of getCatalogs().
>>>Another option would be to put in a check on a call like getTables to see
>>>if a catalog was passed in that is different from the connected catalog
>>>and either throw an Exception or return no results.
>>>
>>>What would make the most sense to you given the server's current
>>>restrictions?
>>
>>Thanks for your answer: at least now I know that there are such
>>restrictions.
>>I think that one of the two options (Exception or no result) will be better
>>and less confusing that a list of tables belonging to another catalog. Let's
>>suppose that we have several catalogs with almost the same tables (some
>>fields different, a table more, a table less as sometimes happens when you
>>have different installation of the same system for different customers...)
>>it could be difficult to understand that we are getting the wrong result
>>(because, for example, we are connected with a wrong connection string) and
>>we could modify data where they should not be modified.
>>
>>My vote is for the Exception: in this way, with a clear message, I can
>>easily understand what the problem is, while an empty result could be also a
>>bug in my code.
>
>
> Thinking about this some more, I don't think an Exception is correct.  We
> don't throw an Exception if the given schema doesn't exist for example.  I
> think we should just return no rows.  The other problem is that some
> getXXX methods don't take a catalog name.  For example getSchemas().
>
>
>>I don't know what you decided at the end of the debate about the result of
>>getCatalogs: my opinion (if you mind it) is that it's ok the actual result
>>(because, at least, one can choose to create a new connection to deal with
>>the other catalogues), above all if the user can see only catalogs to which
>>he has access to (the user in my test can log on every db, so I cannot tell
>>if the behaviour is that I just described).
>>Else, there could be a (very little) security problem.
>
>
> The current getCatalogs() returns all databases whether you can connect to
> them or not.  At the moment I'm leaning towards making this return only
> the current database.  The reason for this is that consider a tool like a
> cross platform database manager/viewer.  (In particular I'm thinking of
> DBVisualizer.)  It presents you with a hierarchy which you can navigate
> down catalog->schema->table type->...  For an application like this how
> could it possibly know that it can't acccess other catalogs?  It wouldn't
> be so bad if navigating into another database came up with nothing, but it
> will return values from the current db for schemas and possibly table
> types.
>
> Perhaps the core of this problem may be that Connection.setCatalog does
> not throw an Exception when given a catalog name other than the current
> one.
>
> Anyway I'm just rambling now.
>
> Kris Jurka
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings