On 12/24/2013 11:17 PM, Dean Rasheed wrote:
I don't think this bit is quite right.
It's not correct to assume that all the view columns are simple
references to columns of the base relation --- auto-updatable views
may now contain a mix of updatable and non-updatable columns, so some
of the
On 12/24/2013 03:21 PM, Abbas Butt wrote:
Could you please explain a little bit more how would you solve the posed
problem using map_variable_attnos?
I was recently working on a similar problem and used the following algo
to solve it.
I had to find to which column of the base table does
On 12/24/2013 03:21 PM, Abbas Butt wrote:
Could you please explain a little bit more how would you solve the posed
problem using map_variable_attnos?
It actually turns out to be even simpler, and easy to do in one pass,
when using ReplaceVarsFromTargetList .
You just generate a temporary new
On 24 December 2013 12:12, Craig Ringer cr...@2ndquadrant.com wrote:
On 12/24/2013 03:21 PM, Abbas Butt wrote:
Could you please explain a little bit more how would you solve the posed
problem using map_variable_attnos?
It actually turns out to be even simpler, and easy to do in one pass,
Hi all
I'm finding it necessary to remap the varno and varattno of Var elements
in RETURNING lists as part of updatable s.b. view processing. A
reference to a view col in RETURNING must be rewritten to point to the
new resultRelation at the top level, so that the effects of BEFORE
triggers are
On 12/24/2013 02:35 PM, Craig Ringer wrote:
So the short version: Given the RTE for a simple view with only one base
rel and an attribute number for a col in that view, and assuming that
the view col is a simple reference to a col in the underlying base rel,
is there any sane way to get the
On Tue, Dec 24, 2013 at 11:47 AM, Craig Ringer cr...@2ndquadrant.comwrote:
On 12/24/2013 02:35 PM, Craig Ringer wrote:
So the short version: Given the RTE for a simple view with only one base
rel and an attribute number for a col in that view, and assuming that
the view col is a simple
