El camino de búsqueda de PostgreSQL no funciona como se anunció

Estoy usando PostgreSQL 9.0.3 en RedHat. La base de datos contiene dos esquemas, public y wh. Creé un nuevo rol llamado django. Quiero que este usuario use el esquema wh ya que es el predeterminado.El camino de búsqueda de PostgreSQL no funciona como se anunció

Siguiendo el manual, lo hice:

ALTER USER django SET SEARCH_PATH TO wh, public;

Esto parece funcionar:

SHOW SEARCH_PATH; 
search_path 
------------- 
wh, public

Sin embargo, si luego hacer un \dt, sólo se muestran las tablas del esquema público. En el manual, cambiar la ruta de búsqueda debería tener un efecto inmediato, y debería poder acceder a las tablas wh sin un prefijo, pero este no es el caso. El inicio y cierre de sesión conserva los cambios en search_path, pero no muestra ningún cambio de comportamiento.

¿Qué me estoy perdiendo?

Fuente

2011-09-13 talonsensei

Esto podría resolver su problema:

GRANT USAGE ON SCHEMA wh TO django;

(. O GRANT de uso para cualquier papel que tiene Django como miembro (directa o indirecta))
(O OTORGUE TODO ... si eso es lo que desea.)

Configurando search_path instruye a Postgres a loo k para objetos en los esquemas listados. No otorga permiso para ver lo que hay allí. Si "django" no tiene los privilegios necesarios, \dt no debe (y no) mostrar esa información.

Por otro lado, si ya lo ha probado como superusuario (según su comentario sobre la sugerencia anterior), entonces puede que no sea así ...

Fuente

2011-09-14 00:18:23

Hola Erwin, ¡Esto funcionó! Es muy extraño para mí que otorgarle un superusuario a este rol no lo logró. Sin embargo, la concesión explícita en el esquema hace que el comportamiento sea correcto. Muchas gracias y gracias a todos los que contribuyeron. – talonsensei

Al consultar una tabla sin calificación de esquema como 'SELECT id FROM mytable', PG dirá' relation 'mytable' does exists', lo cual es un poco engañoso ya que sabes que existe, pero tal vez simplemente no tienes acceso. Por lo tanto, cuando consulte la tabla con un nombre de esquema apropiadamente calificado como 'SELECT id FROM myschema.mytable;' obtendrá el mensaje: 'permission denied for schema ..' que señala claramente un' USO GRANT EN ESQUEMA .. 'declaración es necesaria. Esta es solo una razón más por la que es una buena idea usar nombres de esquema totalmente calificados en consultas. –

Hola Erwin, gracias por la solución, ¡me has salvado! :-) y gracias a talonsensei por iniciar la pregunta aquí :-) – shahjapan

Eso podría ser una limitación del comando \dt.

Para verificar que search_path funciona correctamente, intente ejecutar SELECT * FROM some_table donde some_table es uno que se encuentra en el esquema wh.

Fuente

2011-09-13 20:28:54

Gracias por la sugerencia. Intenté eso, pero me da un error al decir que la tabla no existe. Si prefijo la consulta con wh, funciona. Por lo tanto, no parece ser una limitación \ dt – talonsensei

Acabo de probarlo (solo versiones) 9.1 en Windows de 64 bits y funcionó según lo especificado.

Extracto del ALTER ROLE página de manual:

Las variantes restantes cambian por defecto la sesión de un papel para una variable de configuración , ya sea para todas las bases de datos o, cuando se especifica la cláusula BASE DE DATOS EN , solamente para las sesiones de la base de datos nombrada. Cada vez que el rol inicie una nueva sesión, el valor especificado se convierte en el valor predeterminado de la sesión, anulando cualquier configuración presente en postgresql.conf o recibida de la línea de comandos de postgres. Esto solo ocurre en el momento del inicio de sesión; al ejecutar SET ROLE o SET SESSION AUTHORIZATION no se configuran los nuevos valores de configuración .

(énfasis mío)

Fuente

2011-09-13 22:04:51

Gracias Milen. Ya lo he hecho. Con la función principal de administrador/superusuario, esto funciona y a \ dt solo mostrará tablas en el esquema wh. Sin embargo, por una razón que no entiendo, cuando hago esto para otro usuario, incluso cuando los hice también admin/superusuario, a \ dt solo muestra tablas públicas, no wh, aunque la ruta se modifique. – talonsensei

Si pudiera reproducir esto de manera confiable y pudiera diseñar un pequeño caso de prueba, creo que los desarrolladores querrán saber de usted. Pero primero debes asegurarte de que estás probando/reproduciendo esto en la última versión menor (9.0.4) de la versión principal que estás usando (9.0). –

Gracias Milen. Es reproducible, creo. Probé en las instalaciones de 9.0.1 (Snow Leopard) y 9.0.3 (Redhat). – talonsensei

Para PostgreSQL, si un usuario conectar una base de datos y buscar objetos como una mesa, primero que se busca el esquema tal como el mismo nombre del nombre de usuario, si no lo encuentra, lo hará mirada para el esquema público, En su caso, si conecta la base de datos a través del usuario django, buscará de manera predeterminada el esquema django, pero desea que el esquema actual sea wh, por lo tanto, haga que el nombre del esquema y el nombre sean los mismos, y luego inicie sesión en la base de datos. el rol resolverá tu problema, sin escribir el prefijo, ¡solo inténtalo!

Fuente

2011-09-14 08:47:24 francs

Hola Francs, Tu sugerencia tiene mucho sentido y la probé, pero el espacio de búsqueda predeterminado para el usuario wh sigue siendo "$ user", public y a \ dt still solo muestra tablas públicas La salida de current_schemas (true) es {pg_catalog, public}. Entonces no parece funcionar. – talonsensei

ahora, ¿cuál es su nombre de usuario y nombre de esquema? si la base de datos no es un prod db, puede hacer que los dos tengan el mismo nombre. Y también tenga en cuenta el nombre del propietario de la mesa. – francs

El camino de búsqueda de PostgreSQL no funciona como se anunció

Respuesta

Cuestiones relacionadas