[postgis-devel] RE: WKTRaster news from the Toronto CodeSprint?

[Stephen Frost]

* Frank Warmerdam (warmerdam at pobox.com) wrote:
> Stephen Frost wrote:
>> What is your concern about making these views?  Honestly, in the worst
>> case we'd have to do something like have a side-table that just creates
>> an ID for each new set of options given with the parameters similar to
>> the current tables and then have the view based on that.  At least for
>> users it would still be transparent since you can tailor the
>> input/output for the typmod to be something like:
>>
>> mycolumn    geometry(4269,'POINT',2)
>
> Stephen,
>
> I'm afraid I'm way out of my depth here.  I was told there were only
> 32bits of information to hold information beyond what would be available
> from other sources (I assumed this was the normal column definition info
> in the catalogs), and this clearly was not enough for stuff like a 2D
> double precision extent so I just wrote off the issue.

It's an integer, but it can't be negative, so it's technically 31 bits.
If we need to store something like a 2D extent as part of the type of
the column (which I could maybe see for the raster table, though I'm not
sure I'm really comfortable with that- seems like it should be part of
the data/index rather than a definition of a column?) with double
precision, then no, that can't be done just with the bits available in
typmod.

> I understand a simple metadata table maintained by applications or
> supporting functions. I read what you wrote above, but I have no clue
> what you are talking about.

Ok, I think the 'magic', as it were, is that you can have functions for
the input/output of the typmod *string* that is presented in something
like a CREATE TABLE statement.  That allows you to convert that string
(which you can make whatever you want, so long as you parse it, do
whatever you want with it, and return a non-negative integer to PG) into
something which is stored in the PG catalog tables.

> I don't mind it being a view as long as
> I can have the various bits of info I want, and as long as it is reasonably
> straight forward how I would update stuff (for an application library like
> GDAL for instance), and as long as it being a view isn't going to make it
> slow to access.

Basically, you would be joining the PG catalog table entry with the
side-table to pull the attributes you need, in that case.  In the case
where the information is encoded into the typmod, there would be helper
functions to translate the typmod into the different pieces of
information which are stored in it.

I doubt very much that performance would be bad, since we would index
the side-table appropriately, of course, but I'm all for doing
performance testing to ensure there is no regression.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090313/2c0212b5/attachment.sig>