Allow COPY to topology edge view

[strk]

It takes a trigger to allow COPY to view. We only expose a RULE.

ERROR:  cannot copy to view "edge"
HINT:  To enable copying to a view, provide an INSTEAD OF INSERT trigger.

It would be nice to allow inserts to edge

[robe]

are you planning to still do this for 3.3.0. Get it done before we call beta1

[pramsey]

Any interest in just moving the edge_data information into edge and dropping the view? It's totally unclear to me what the indirection of using a view buys, and that it's worth the price.

[pramsey]

To complete the thought: had I been looking at the original edge table and been thinking "I need to add a directionality flag to the right/left face information" I'd have just added two booleans to the end of the edge table to flag the directionality. very small, additive-only change.

I think the goal of "hewing to the standard" kind of falls apart when what you are adding (the capability to store rings that include a self-intersection in the form of a "spike") is a capability the original standard didn't anticipate. I imagine if you brought it to the SQL/MM folks they'd say "uh, no, you should only have OGC valid rings participating in faces". So you're in uncharted waters, change the edge table slightly to sail safely through.

[strk]

You got me curious about directionality of right/left face information. What information would they be adding ? Winding of the ring ?

I've also been thinking about adding more fields, kind of caches, to speed things up. For example to quickly find the EXTERIOR ring of a face (maybe same thing you're trying to do with a winding info?).

The view only buys us compatibility with the standard, yes.

Capability to store spikes is already supported by the standard, or at least I haven't found a clear proof of them being invalid. A Spike is an edge partecipating in a ring twice (once forward, once backward). See GetRingEdges.