Bug report #741

identify not working for some postgis layers

Added by Redmine Admin about 13 years ago. Updated about 11 years ago.

Status:Closed
Priority:Low
Assignee:nobody -
Category:Data Provider
Affected QGIS version: Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:10800

Description

Identify returns no features found when in fact features are within the region clicked.

Looking at the query sent to the server it seems that there are two problems:

  • the column names aren't being properly quoted so this will raise an error and abort the xaction.
  • all columns are being converted to text and not all columns are convertible to text. In my case I had a bytea column and that raised an error which aborted the transaction.

This might also affect the attribute table.

qgspostgresprovider.cpp.diff Magnifier - patch fixing part of ticket 741..... I think (815 Bytes) Redmine Admin, 2007-07-26 03:08 PM

Associated revisions

Revision c58893d4
Added by Gary Sherman almost 13 years ago

Revert changes made to fix #741 since it appears to break more than it fixes

git-svn-id: http://svn.osgeo.org/qgis/trunk/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision c6c8128f
Added by Gary Sherman almost 13 years ago

Revert changes made to fix #741 since it appears to break more than it fixes

git-svn-id: http://svn.osgeo.org/qgis/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

History

#1 Updated by Redmine Admin about 13 years ago

Further, when the tool does identify a feature (i.e. neither of the aforementioned problems raise an error and aborts the transaction) the primary key of the table always comes back as 0. Also affects the attribute table.

#2 Updated by Gary Sherman almost 13 years ago

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

Patch applied. Please test to make sure it solves the issue and doesn't introduce any other issues.

#3 Updated by Marco Hugentobler almost 13 years ago

  • Resolution deleted (fixed)
  • Status changed from Closed to Feedback

The problem with this patch is that all the numeric columns now appear as 0. This is because their values are now transfered in binary format, but in the postgresprovider, they are interpreted as strings.

The problem with the primary key coming as 0 has already been adressed in a former fix.

#4 Updated by Gary Sherman almost 13 years ago

So is the issue only the handling of bytea fields?

#5 Updated by Jürgen Fischer almost 13 years ago

  • Resolution set to fixed
  • Status changed from Feedback to Closed

the quoting part looks like a good thing. You could have mixed-case or uppercase column names that postgres will choke on unless properly quoted.

There's no support for BLOB attributes in QGIS anywhere anyway, so it's probably best to simply ignore columns that are of unsupported types, ie. bytea and maybe more.

I did that with f35fb37d (SVN r7444).

#6 Updated by Anonymous about 11 years ago

Milestone Version 0.9.1 deleted

Also available in: Atom PDF