[Gdal-dev] Text field size ogr2ogr PostgreSQL to MIF/MID

[Mateusz Loskot]

Frank Warmerdam wrote:
> Mateusz Loskot wrote:
>> Frank Warmerdam wrote:
>>> Marc Jacquin wrote:
>>>> Hi all,
>>>>
>>>> I am using ogr2ogr to convert a PG table into MIF/MID.
>>>> The table fields are varchar(x) or char(x) type and the field width is
>>>> never
>>>> more than let say 50.
>>>>
>>>> It seems that ogr2ogr forces text fields to be 254 wide. But when
>>>> you get
>>>> more than 20 fields the record size exceeds the 4 K limit of MapInfo 6.
>>>>
>>>> Is there a PG usable type so that ogr2ogr would keep the width for
>>>> exporting?
>>> Marc,
>>>
>>> It looks like the CHARACTER(n) field type in Postgres will be treated by
>>> OGR as a field with a particular width.  The code that decides whether
>>> to associate a width with text fields in the driver looks like this:
>>
>> Frank,
>>
>> Isn't it correct assumption?
>> I'm not sure I understand where is the problem here, but as I know,
>> CHARACTER(n) type should be handled as fixed-width type.
> 
> Mateusz,
> 
> The problem Marc was running into is that many text field types,
> like VARCHAR(n) do not end up with widths associated with them and
> he wanted to know if there was a type that does.   I think CHARACTER(n)
> does, which would be good.

Frank,

Yes, I understand it now, after I got short explanation
on the #gdal channel.

>> I may not understand rationale behind the code above well, but using
>> libpq it's possible to retrieve lenght of character type from result
>> set, using PQfmod() function:
>>
>> //////////////////////////////////////////////////////
>> const int VARCHAR_HDRSZ = 4; // usually, equal to sizeof(int)
>>
>> int fmod = PQfmod(hResult, iColumnIndex);
>> if (-1 != fmod)
>>    length = (fmod - VARCHAR_HDRSZ);
>> //////////////////////////////////////////////////////
> 
> Note that for tables we actually query various supporting tables
> to get types, widths etc.  We only inspect the resultset itself for
> this information from ExecuteSQL() results.

Right. I missed this details.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net