Feature request #1021

PostGIS layers lose the "public" schema in the table part of the URI

Added by Steven Mizuno over 12 years ago. Updated about 11 years ago.

Assignee:Jürgen Fischer
Category:Data Provider
Pull Request or Patch supplied: Resolution:wontfix
Easy fix?:No Copied to github as #:11081


Have found this problem in 0.9.1: when a table in the public schema has symbology set up or a where clause set, the schema portion of the table disappears from the "Source for this layer" item in properties/metadata. When a project is saved, then loaded, that layer won't load.

HEAD has the same behavior as far as the schema being cleared, but the project layer will load.

I believe that this would affect any table whose schema is the current schema in the database.

Have found in qgspostgresprovider.cpp: in the constructor, about line 160 when the current schema is tested and equals the table's schema, mUri.clearSchema() is called. Then setDataSourceUri(mUri) is called.

Several lines in this area are unnecessary as mCurrentSchema is tested/set here and never used anywhere else.

I believe the table's schema should be preserved throughout all operations; I don't see any particular advantage other than a slightly shorter query string being sent to the database.

summary of patch submitted:

1. qgspostgresprovider.cpp : in the constructor, removed "current_schema()" from the sql command that retrieves table privileges; removed the various tests and setting of variables relating to current_schema / mCurrentSchema; retained the setDataSourceUri() call

2. qgspostgresprovider.h : removed mCurrentSchema from the header

patch_for_bug_1021.txt Magnifier (1.63 KB) Steven Mizuno, 2008-03-31 07:41 PM


#1 Updated by Jürgen Fischer over 12 years ago

  • Resolution set to wontfix
  • Status changed from Open to Closed

actually this is intentional and mimics OGR. See #843.

#2 Updated by Anonymous about 11 years ago

Milestone Version 0.9.2 deleted

Also available in: Atom PDF