Hi Martin,
what is the reason for r54684? It breaks a core functionality, i.e.
the output of vector_columns in lib/python/scripts/vector.py has now
changed and various scripts rely on that output. I have reverted
r54684 in 55475. The commit comment does not make sense to me because
db_sqltype_name() has never returned the width or precision.
Markus M
Hi,
2013/3/21 Markus Metz <markus.metz.giswork@gmail.com>:
what is the reason for r54684? It breaks a core functionality, i.e.
the output of vector_columns in lib/python/scripts/vector.py has now
changed and various scripts rely on that output. I have reverted
r54684 in 55475. The commit comment does not make sense to me because
db_sqltype_name() has never returned the width or precision.
this change was related to `v.out.postgis` development. Hm, you are
right. I was not aware enough of possible consequences. I agree with
this revert.
Thanks, Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Sat, Mar 23, 2013 at 5:37 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/3/21 Markus Metz <markus.metz.giswork@gmail.com>:
what is the reason for r54684? It breaks a core functionality, i.e.
the output of vector_columns in lib/python/scripts/vector.py has now
changed and various scripts rely on that output. I have reverted
r54684 in 55475. The commit comment does not make sense to me because
db_sqltype_name() has never returned the width or precision.
this change was related to `v.out.postgis` development. Hm, you are
right. I was not aware enough of possible consequences. I agree with
this revert.
I noticed that 'CHARACTER' is used whenever the field width is known,
otherwise 'TEXT' is used. IOW, TEXT is what you probably mean with
CHARACTER VARYING. Note that e.g. within sqlite, varchar becomes TEXT
and varchar (%d) becomes CHARACTER.
Markus Metz
Hi,
On 25 March 2013 09:49, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Sat, Mar 23, 2013 at 5:37 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/3/21 Markus Metz <markus.metz.giswork@gmail.com>:
what is the reason for r54684? It breaks a core functionality, i.e.
the output of vector_columns in lib/python/scripts/vector.py has now
changed and various scripts rely on that output. I have reverted
r54684 in 55475. The commit comment does not make sense to me because
db_sqltype_name() has never returned the width or precision.
this change was related to `v.out.postgis` development. Hm, you are
right. I was not aware enough of possible consequences. I agree with
this revert.
I noticed that 'CHARACTER' is used whenever the field width is known,
otherwise 'TEXT' is used. IOW, TEXT is what you probably mean with
CHARACTER VARYING.
Note that e.g. within sqlite, varchar becomes TEXT
and varchar (%d) becomes CHARACTER.
With sqlite3, all CHARACTER(%d)s, VARCHAR(%d)s, etc. become TEXT. [1]
Vaclav
[1] http://www.sqlite.org/datatype3.html
On Mon, Mar 25, 2013 at 2:09 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Hi,
On 25 March 2013 09:49, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Sat, Mar 23, 2013 at 5:37 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/3/21 Markus Metz <markus.metz.giswork@gmail.com>:
what is the reason for r54684? It breaks a core functionality, i.e.
the output of vector_columns in lib/python/scripts/vector.py has now
changed and various scripts rely on that output. I have reverted
r54684 in 55475. The commit comment does not make sense to me because
db_sqltype_name() has never returned the width or precision.
this change was related to `v.out.postgis` development. Hm, you are
right. I was not aware enough of possible consequences. I agree with
this revert.
I noticed that 'CHARACTER' is used whenever the field width is known,
otherwise 'TEXT' is used. IOW, TEXT is what you probably mean with
CHARACTER VARYING.
Note that e.g. within sqlite, varchar becomes TEXT
and varchar (%d) becomes CHARACTER.
With sqlite3, all CHARACTER(%d)s, VARCHAR(%d)s, etc. become TEXT. [1]
This is the sqlite affinity, but the GRASS sqlite driver checks first
the declared datatype with sqlite3_column_decltype(), then the
affinity type if decltype is not available. Sqlite type and
DB_SQL_TYPE_* are not identical.
Markus M
Vaclav
[1] http://www.sqlite.org/datatype3.html