Where are on updatable views?
---
Bernd Helmle wrote:
--On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
So in other words, views on serial columns don't work? I don't think
that's
--On Donnerstag, März 06, 2008 17:03:10 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
Where are on updatable views?
I really want to have this one ready for 8.4, but i have nothing appliable
at the moment. Considering the amount of rework that needs to be done, i
hope i can provide an
On Thu, Mar 6, 2008 at 6:35 PM, Bernd Helmle [EMAIL PROTECTED] wrote:
--On Donnerstag, März 06, 2008 17:03:10 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
Where are on updatable views?
I really want to have this one ready for 8.4, but i have nothing appliable
at the moment. Considering
Here is the more recent email I have on this feature work.
---
Bernd Helmle wrote:
--On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
So in other words, views on serial columns don't
Where are we on this feature?
---
Bernd Helmle wrote:
--On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Bernd Helmle wrote:
--On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
So in
Bernd Helmle [EMAIL PROTECTED] writes:
I would like to try to grab your idea to push down the CHECK OPTION logic
down to the executor as a (table/view?) constraint. Would that be an idea
worth to consider and,
most important, is this doable? I don't have that much experience in the
--On Donnerstag, August 31, 2006 11:10:47 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
The problem is not with the view condition. Consider
CREATE TABLE data (id serial primary key, ...);
CREATE VIEW only_new_data AS SELECT * FROM data WHERE id 12345
WITH CHECK
Bernd Helmle wrote:
[EMAIL PROTECTED] wrote:
* It's too early in the morning for me to be clear about the difference
between CASCADED and LOCAL CHECK OPTION --- I think that this would
merely alter the set of check constraints collected for a particular
query, but if there's something more
Bernd Helmle [EMAIL PROTECTED] writes:
What we can do is to restrict view updates that involves a volatile function
completely. As soon as the rewriter wants to apply an implicit system rule
to a current query which holds volatile functions, we could treat this as
an error.
So in other
[Quick note: sorry if you received this mail multiple times,
i've moved to a new workstation and my MUA gots hosed up
with its identities (all of them has the same adress, suddenly)
and I recognized that too late.i'm sorry]
--On Freitag, September 01, 2006 10:03:42 -0400 Tom Lane
[EMAIL
On 9/1/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Bernd Helmle wrote:
[EMAIL PROTECTED] wrote:
* It's too early in the morning for me to be clear about the difference
between CASCADED and LOCAL CHECK OPTION --- I think that this would
merely alter the set of check constraints collected
--On Freitag, September 01, 2006 11:34:49 -0400 Alvaro Herrera
[EMAIL PROTECTED] wrote:
I don't understand this part very well. Say if you have a view WITH
CHECK OPTION whose condition is foo 5, and then define a view WITH
LOCAL CHECK OPTION on top of that, whose condition is bar 5. Does
--On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
So in other words, views on serial columns don't work? I don't think
that's going to be acceptable.
They work in such a case that someone isn't allowed to put a volatile
function in an update query
Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out. What is all the stuff about
handling multiple base rels?
--On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out.
But later SQL
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
I'm unclear as to why you've got DO INSTEAD NOTHING rules in there ---
You need to have one unconditional rule if you have a bunch of
conditional ones. The system does not see through the fact that the
conditional ones cover all
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
The proposed WITH CHECK OPTION implementation is unworkable for exactly
this reason --- it will give the wrong answers in the presence of
volatile functions such as nextval().
I'm not sure why
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out. What is all the stuff about
handling multiple base
On Wed, Aug 30, 2006 at 12:01:25PM -0400, Tom Lane wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling
Bernd Helmle [EMAIL PROTECTED] writes:
While working on Alvaro's suggestions to fix the code i got the opinion
that we need to reject any attempts to name a user defined rule
as
_INSERT
_NOTHING_INSERT
_DELETE
_NOTHING_DELETE
_UPDATE
_NOTHING_UPDATE
If the code is dependent on
On 8/24/06, Tom Lane [EMAIL PROTECTED] wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
While working on Alvaro's suggestions to fix the code i got the opinion
that we need to reject any attempts to name a user defined rule
as
_INSERT
_NOTHING_INSERT
_DELETE
_NOTHING_DELETE
_UPDATE
--On Donnerstag, August 24, 2006 11:00:45 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
If the code is dependent on recognizing names to know what it's doing,
then I'd say you have a fundamentally broken approach. Consider adding
a flag column to pg_rewrite to distinguish these rules, instead.
--On Donnerstag, August 24, 2006 11:02:43 -0500 Jaime Casanova
[EMAIL PROTECTED] wrote:
Actually the code delete implicit rules based on a field added to
pg_rewrite but that catalog has a unique index on ev_class, rulename:
pg_rewrite_rel_rulename_index UNIQUE, btree (ev_class, rulename)
i
25 matches
Mail list logo
