[GRASS5] Postgres text

[Thierry Laronde]

Hello,

On Wed, Nov 12, 2003 at 05:28:23PM +0100, Radim Blazek wrote:
> Anybody has idea, how to support postgres type 'text', in dbmi-pg driver?
> 
> I know about 3 solutions and I don't like any of them:
> 
> 1) Don't support text type (ignore such fields and print warning)
> 2) Assign some fixed length to text field (and print warning) like OGR(?).
>    This way users can simply lose data.
> 3) Add DB_SQL_TYPE_TEXT to GRASS. The problem is, that text is not supported by
>    dbf driver, so any attempt to copy tables with text to dbf fails.
>    This also means to make more changes in existing modules and libraries.
> 

Since my reflexions are not very popular, what follows is given FWIW.

I have given a look at the code for another type (DBF) both in
src.garden and in current DBMI in order to see if some bugs reported by
users were 1: confined to "old" 5.0/5.3; 2: easily solvable.

Since the answer is that the inaccuracy is in the DBF library (from GDAL
I think) and since this very same code is used in DBMI the problem was
still a present one (this answers 1: ). Was the inaccuracy easily
solvable? No.

So I have thought about the way (and that's where it might be related to
your questions) to handle the sources in such a manner that no lost of 
data occurs (this is in my opinion an absolute requisit).

Since the only solution, because all the formats are distincts and all
databases handle the data in different ways is _not_ to filter the data
from one database to several others (we loose information at every step)
I have imagined to create a GUARD (Grass Uniform Ascii Representation of
Data) i.e. a GRASS ascii format for DB (symetric of the
vector ascii) since every data (binary being represented for example 
as hexadecimal), every indefinite accuracy in number can be represented
in a text form we would be sure, at least, by converting one format to 
GUARD, to have in GUARD the exact initial data. 

And if one wants to convert to everything other let the conversion 
cast maximal precision GUARD in something perhaps less accurate 
(but this will be done under the user responsability: she will know 
that by casting informations she will potentially loose precision/data).

The side effect question is: what kind of DB should GRASS supports
internally/natively? This has something to do with the organization of
code and the segregation between core system ("kernel" and libes) and
drivers (access to peripheral resources) (that I have sketched in
another mail).

Indeed, dig_atts (for example) was for vector the native DB interfaces
(layers being treated as several different maps in the MAPSET) with
limited possibilities (double indirection to go from geometrical
elements to named attributes via attributes number). i
So we should propose something "else" that could independently, easily 
and efficiently been used and interfaces with DBMI modules (and indeed, 
I think we should use, for example for vector, an unique identifier for
each element being used as an index to an unlimited numbers of "text"
fields: the calculations, huge manipulation of data should be made
in a real RDBM, we don't need these in core).

Please note too that major benefits of ASCII (more generally text)
files are:
- ease of portability
- ease of storage in CVS for example

We don't need to _work_ on an ascii file (can be translated in a compact
binary format) but we need to be able to export and import to/from it.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde at polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C