Bug report #13857
Default values on a PG table: type cast appended
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Jürgen Fischer | ||
| Category: | Data Provider/PostGIS | ||
| Affected QGIS version: | 2.8.3 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 21880 |
Description
If the table has a default value, this is used in QGIS, but quotes and a type cast is added to it, e.g.:
'test123'::character varyinginstead of:
test123Related issues
Associated revisions
History
#1
Updated by Jürgen Fischer over 8 years ago
- Status changed from Open to Feedback
Defaults values are kept verbatim (not only for 'test123'::character varying, but also nextval('foo_id_seq'::regclass)). What's the problem with it?
#2
Updated by Paolo Cavallini over 8 years ago
e.g. if I insert a path to a photo, and set the field widget to photo, the image itself fails to be displayed because of the additional text added.
#3
Updated by Paolo Cavallini over 8 years ago
If the table does not have a PK, and only one field, apparently the cast is not added.
#4
Updated by Jürgen Fischer over 8 years ago
Paolo Cavallini wrote:
If the table does not have a PK, and only one field, apparently the cast is not added.
Can't reproduce that with:
qgis=> create table issue13857(file varchar default '/tmp/foo.png');
CREATE TABLE
qgis=> \\d issue13857
Table "public.issue13857"
Column | Type | Modifiers
--------+-------------------+-------------------------------------------
file | character varying | default '/tmp/foo.png'::character varying
#5
Updated by Paolo Cavallini over 8 years ago
OK, so last think must have been a local mistake. Sorry about the noise.
#6
Updated by Giovanni Manghi over 8 years ago
- Resolution set to invalid
- Status changed from Feedback to Closed
#7
Updated by Paolo Cavallini over 8 years ago
- Status changed from Closed to Reopened
Giovanni, please don't close valid issues. Thanks.
#8
Updated by Giovanni Manghi over 8 years ago
- Resolution deleted (
invalid)
Paolo Cavallini wrote:
Giovanni, please don't close valid issues. Thanks.
didn't you stated it was a 'local mistake'?
#9
Updated by Giovanni Manghi over 8 years ago
- Status changed from Reopened to Feedback
#10
Updated by Paolo Cavallini over 8 years ago
- Status changed from Feedback to Open
This refers to the PK issue, not to the main one, which is still valid.
#11
Updated by Giovanni Manghi over 8 years ago
- Status changed from Open to Feedback
I cannot confirm the specific issue described here, a default defined as
'test123'::character varying
returns as expected
test123
after adding new records and saving.
On the other hand a default defined as
('now'::text)::date
(in a date column of course), works if adding a record in pgadmin (and other backends) but in QGIS does not work and it returns always NULL.
QGIS 2.8.4, pgsql 9.3 and postgis 2.1
#12
Updated by Jürgen Fischer over 8 years ago
Giovanni Manghi wrote:
('now'::text)::date
(in a date column of course), works if adding a record in pgadmin (and other backhands) but in QGIS does not work and it returns always NULL
QGIS 2.8.4, pgsql 9.3 and postgis 2.1
works fine for me in master too (PostgreSQL 9.4)
#13
Updated by Giovanni Manghi over 8 years ago
Jürgen Fischer wrote:
Giovanni Manghi wrote:
('now'::text)::date
(in a date column of course), works if adding a record in pgadmin (and other backhands) but in QGIS does not work and it returns always NULL
QGIS 2.8.4, pgsql 9.3 and postgis 2.1works fine for me in master too (PostgreSQL 9.4)
confirmed also in another platform that on master
('now'::text)::date
works ok but not on 2.8.5, while
'test123'::character varying
works as expected on both.
#14
Updated by Jürgen Fischer over 8 years ago
- Status changed from Feedback to Closed
Fixed in changeset 4c3cf64f01af32511ef5fc56b0b13aa705c00dd6.