On Wed, Mar 6, 2013 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the other hand, I don't have a problem with decreeing that
non-Postgres FDWs need to use PK row identification in the first
release; which would be the consequence if we don't do anything about
allowing new system columns
On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru Hanada shigeru.han...@gmail.com writes:
I'm not sure whether postgres_fdw should support, but updatable views
have no system column including ctid. So, we need magic identifier,
perhaps it would be set of primary key
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 6, 2013 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the other hand, I don't have a problem with decreeing that
non-Postgres FDWs need to use PK row identification in the first
release; which would be the consequence if we don't do
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I considered that. I thought seriously about proposing that we
forget magic row identifiers altogether, and instead make postgres_fdw
require a remote primary key for a foreign
On Wed, Mar 13, 2013 at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I considered that. I thought seriously about proposing that we
forget magic row identifiers altogether, and
Merlin Moncure mmonc...@gmail.com writes:
I just find it odd that rowid concept is used at all without strong
guarantee that the record you are referencing is the one you are
supposed to be referencing. Basically I'm saying PKEY semantics are
the correct ones and that ctid is ok to use iff
On 2013-03-13 09:51:59 -0500, Merlin Moncure wrote:
On Wed, Mar 13, 2013 at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I considered that. I thought seriously about proposing
Andres Freund and...@2ndquadrant.com writes:
Perhaps pgsql-fdw should make sure the update was performed *without*
following the ctid chain to a new valid tuple?
I did think about these issues before committing the patch ;-)
The basic theory in PG's existing design is to postpone locking rows
On Wed, Mar 13, 2013 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
Perhaps pgsql-fdw should make sure the update was performed *without*
following the ctid chain to a new valid tuple?
I did think about these issues before committing the patch ;-)
Merlin Moncure mmonc...@gmail.com writes:
As long as lock as held between ctid examination and row modification
you are ok. didn't read the patch, just pointing that out (history is
full of client side drivers that did not do this properly).
I also might have missed some of the finer
2013/3/6 Tom Lane t...@sss.pgh.pa.us:
Also, the right way to deal with this desire is to teach the planner in
general, not just FDWs, about pushing expensive calculations down the
plan tree --- basically, resurrecting Joe Hellerstein's thesis work,
which we ripped out more than ten years ago.
On 2013-03-05 19:30:53 -0500, Tom Lane wrote:
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
In the context of postgres_fdw, I am not sure if we need an additional
system column like a node_id. Would there be a possibility where
tuples to-be-modified are coming from different foreign tables and at
runtime
On 06-Mar-2013, at 4:12 PM, Shigeru Hanada shigeru.han...@gmail.com wrote:
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
In the context of postgres_fdw, I am not sure if we need an additional
system column like a node_id. Would there be a possibility where
On Wed, Mar 6, 2013 at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
For postgres_fdw, that would really be enough, since it could just
cause a ctid column to be created with the usual definition. Then
it could put the remote ctid into the usual t_self field in returned
tuples.
I'm not sure
Shigeru Hanada shigeru.han...@gmail.com writes:
I'm not sure whether postgres_fdw should support, but updatable views
have no system column including ctid. So, we need magic identifier,
perhaps it would be set of primary key value(s), to support updating
remote updatable views via foreign
Kohei KaiGai kai...@kaigai.gr.jp writes:
2013/3/6 Tom Lane t...@sss.pgh.pa.us:
I think if we're going to support magic row identifiers, they need to
be actual system columns, complete with negative attnums and entries
in pg_attribute.
Sorry, -1 for me.
The proposed design tried to kill two
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily have such a thing. (Oracle has
a rowid that acts a
Tom,
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily have such a thing. (Oracle has
a rowid
On Wed, Mar 6, 2013 at 6:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
+1 for adding a new system attribute. We did something similar in
Postgres-XC, though problem there was much simpler because we always
knew that the remote FDW is a Postgres instance running the same
version. So we
2013/3/6 Tom Lane t...@sss.pgh.pa.us:
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily have such
Committers,
The writable foreign tables patch is flagged ready for committer. While
its last activity was in late 2012, I haven't noticed much else changing
in the area that'd be likely to break it, and FDWs are a somewhat
immature feature anyway. It's been revised based on initial reviews.
Is
Craig Ringer cr...@2ndquadrant.com writes:
The writable foreign tables patch is flagged ready for committer. While
its last activity was in late 2012, I haven't noticed much else changing
in the area that'd be likely to break it, and FDWs are a somewhat
immature feature anyway. It's been
24 matches
Mail list logo
