Bug report #13857: Default values on a PG table: type cast appended - QGIS Application - QGIS Issue Tracking

Bug report #13857

Default values on a PG table: type cast appended

Added by Paolo Cavallini about 9 years ago. Updated almost 9 years ago.

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 varying

instead of:

test123

Related issues

Associated revisions

Revision 4c3cf64f
Added by Jürgen Fischer almost 9 years ago

edit widgets: keep default values of new feature's attributes until they are added
(fixes #12391 & #12386 & #13857)

(cherry picked from commit bfb8ab6893d5bf77b4ae92c6c90e0b5b9c7e9ae7)

History

#1 Updated by Jürgen Fischer about 9 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 about 9 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 almost 9 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 almost 9 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 almost 9 years ago

OK, so last think must have been a local mistake. Sorry about the noise.

#6 Updated by Giovanni Manghi almost 9 years ago

Resolution set to invalid
Status changed from Feedback to Closed

#7 Updated by Paolo Cavallini almost 9 years ago

Status changed from Closed to Reopened

Giovanni, please don't close valid issues. Thanks.

#8 Updated by Giovanni Manghi almost 9 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 almost 9 years ago

Status changed from Reopened to Feedback

#10 Updated by Paolo Cavallini almost 9 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 almost 9 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 almost 9 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 almost 9 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.1

works fine for me in master too (PostgreSQL 9.4)

confirmed also in another platform that on master