On 14 August 2010 23:22, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'll try to post an updated patch then, with some real trigger code,
I've moved this to a new thread, with a WIP patch that allow 3 types
of triggers to be added to VIEWs:
On Mon, Aug 16, 2010 at 09:05:12AM +0100, Dean Rasheed wrote:
On 14 August 2010 23:22, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'll try to post an updated patch then, with some real trigger
code,
I've moved this to a new thread, with a WIP patch that allow 3 types
of triggers to be
On 16 August 2010 14:45, David Fetter da...@fetter.org wrote:
Please add this to the next commitfest :)
Done.
Thanks,
Dean
https://commitfest.postgresql.org/action/commitfest_view?id=7
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM:
On 2010-08-08 1:45 PM +0300, I wrote:
On 8/8/2010 12:49 PM, Dean Rasheed wrote:
For those migrating code from Oracle, providing this feature as-is
might be valuable, since presumably they are not too concerned about
these concurrency issues. Ideally we'd want to do better though.
Yes, you
On 14 August 2010 13:12, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 2010-08-08 1:45 PM +0300, I wrote:
On 8/8/2010 12:49 PM, Dean Rasheed wrote:
For those migrating code from Oracle, providing this feature as-is
might be valuable, since presumably they are not too concerned about
On 7 August 2010 10:56, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
The problem is that this isn't even nearly sufficient. I gave this some
more thought while I was away, and it seems that I missed at least one more
important thing: the WHERE clause. Imagine this query:
DELETE FROM
On 8/8/2010 12:49 PM, Dean Rasheed wrote:
On 7 August 2010 10:56, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi wrote:
The problem is that this isn't even nearly sufficient. I gave this some
more thought while I was away, and it seems that I missed at least one more
important thing: the WHERE
On 8/6/2010 10:49 AM, Dean Rasheed wrote:
On 4 August 2010 15:08, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi wrote:
I'm mainly concerned about concurrently running transactions.
Once again, I think I mis-understood your point. I think that the
database can't really lock anything before
On 4 August 2010 15:08, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010 14:43, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi
wrote:
I'm not sure I understand. RETURNING in DELETE on a table fetches the
old
value after it was
aoa how can i connect my postgres database to manifold?
Regards?
On Fri, Aug 6, 2010 at 12:49 PM, Dean Rasheed dean.a.rash...@gmail.comwrote:
On 4 August 2010 15:08, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi
wrote:
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010
On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
Does this sound like a useful feature? Is this a sane approach to
implementing it? If not, has anyone else given any thought as to how
it might be implemented?
I didn't look at the patch, but so far, I've identified three problems
with the existing
On 4 August 2010 13:22, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
Does this sound like a useful feature? Is this a sane approach to
implementing it? If not, has anyone else given any thought as to how
it might be implemented?
I didn't
On 8/4/10 4:31 PM +0300, Dean Rasheed wrote:
1) You can't re-evaluate the UPDATE expression like an UPDATE on a
table does. Consider for example UPDATE foo SET a=a+1; If the
tuples change before we get to them, we lose data because we
simply can't re-evaluate a+1 in
On 4 August 2010 14:43, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
3) You can't set the RETURNING results. You suggested that
RETURNING for DELETE would return the OLD value, but that seems
broken because that's not necessarily what was deleted.
Well that's what
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010 14:43, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi wrote:
I'm not sure I understand. RETURNING in DELETE on a table fetches the old
value after it was DELETEd, so it really is what the tuple was before the
DLETE, not what is seen
15 matches
Mail list logo
