Re: bug with fkey-dialog in tables belonging to
От | Andreas Pflug |
---|---|
Тема | Re: bug with fkey-dialog in tables belonging to |
Дата | |
Msg-id | 43A57FB1.3010304@pse-consulting.de обсуждение исходный текст |
Ответ на | bug with fkey-dialog in tables belonging to schemes (Harald Armin Massa <haraldarminmassa@gmail.com>) |
Список | pgadmin-support |
Harald Armin Massa wrote: > I discovered a subtle bug within the dialog for foreign key creation: > > Be there a database "testdb" structured like: > > CREATE SCHEMA nb1; > > CREATE TABLE nb1.hauptbaer ( > id_baer serial NOT NULL, > fischfeld text > ); > > ALTER TABLE nb1.hauptbaer > ADD CONSTRAINT hauptbaer_pkey PRIMARY KEY(id_baer); > > CREATE TABLE nb1.nebenbaer ( > id_nb serial NOT NULL, > rede text, > id_baer integer > ); > > ALTER TABLE ONLY nb1.nebenbaer > ADD CONSTRAINT nebenbaer_pkey PRIMARY KEY (id_nb); > > that is, within schema "nb1" there are two tables "nb1.hauptbaer" and > "nb1 nebenbaer". > > The database, the schema, everthing is owned by a user named nb1. > > Now create a connection to the database testdb as user nb1. > > When going to "nebenbaer" and trying to add a foreign key constraint to > id_baer of hauptbaer... > > you can select hauptbaer from the list of tables, but there is no scheme > prefix. On the dialog-tab where you need to select the columns for the > fkey relationship, no column from hauptbaer is shown. I did exactly this, replacing nb1 by user/db/schema postgres, and everything worked as expected. My search_path is the default $user,public. Actually, suppressing the schema name here wouldn't do any harm, because the search_path will automatically add the username here. Regards, Andreas
В списке pgadmin-support по дате отправления: