#4843 closed defect (fixed)
VRT incorrectly limits string width
Reported by: | jpalmer | Owned by: | Even Rouault |
---|---|---|---|
Priority: | normal | Milestone: | 1.10.0 |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | vrt field width |
Cc: |
Description
The below changeset forced VRT string width definitions to be less than 1024. There should be no constraint at all. PG sources allow for much larger 32bit field widths. Can this please be removed?
As an example see this vrt csv data source that can be loaded in 1.9:
ogr2ogr -f "PostgreSQL" "PG:host=localhost dbname=my_db" nz-primary-parcels.vrt -lco GEOMETRY_NAME=shape -lco SCHEMA=public -nln test_parcels
data here https://dl.dropbox.com/u/30623980/data.tar.gz
Change here:
http://trac.osgeo.org/gdal/changeset/24635/trunk/gdal/ogr/ogrsf_frmts/vrt/ogrvrtdatasource.cpp
Change History (2)
comment:1 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 12 years ago
Thanks heaps. You really are the new champion of gdal/ogr!
The other thing I noticed when creating a postgresql layer table and the field creation failed, is a table still existed in the db with the just ogc_id and geometry columns. Maybe the whole table creation and addition of fields should be wrapped into a single transaction? Maybe the whole create table, add fields, and insertion of data should be in a single transaction..?
Limitation removed in r25029. I remember I have put it for a (good) reason. Huge field width causes a problem in one driver, but I don't remember anymore which one. I should have documented it in the original commit message