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

[Stephen Frost]

Chris,

* Chris Hodgson (chodgson at refractions.net) wrote:
> The side table seems like the only way to reliably fit all of our type  
> information into the 31 bits of typmod. It works as long as there are no  
> more than 2 billion differently-defined geometry columns, which I think  
> is an acceptable limitation. But where does this side-table end up  
> living? Isn't it just going to have the same problems as the  
> geometry_columns table?

It all depends on the max size of an SRID..  If we can define it to be
less than 1M (I believe that was it), then I think it can all fit in a
31 bit typmod.  If not, we need the side-table.

The nice thing about using typmod is that you control the input/output
functions for parsing/storing the bits inside the ()'s in a column
definition (eg: geometry(4269,'POINT',1)).  What that means is that the
side table has to exist (and can live anywhere, really, as long as it
can be referenced/used from the typmod-handling function) to store
stuff, but the internal values it uses (the sequence of numbers from 1
to 2billion) are never seen by the user or anything else (pg_dump, etc)
unless they decide they go looking in that side table.

If that side-table ends up changing through some external action, things
can get ugly though, which is why I'd prefer to not have it.  For
example, a pg_dumpall would dump all the tables with their textual
representations, which is good, but when the data is reloaded either the
side table would have to not be loaded at all, created as empty, or
created and loaded *before* everything else.  See what I mean about how
that could be a problem?  Though if we just add it to pg_catalog, maybe
it would get ignored and we'd be alright..  Havn't looked into that yet.

I've been planning to build up a proof-of-concept for both approaches, I
just havn't had time.

	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/6db998c5/attachment.sig>