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 mome
--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 up
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
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 column
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 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:
>
> >
>
--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
N
--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".
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 co
[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
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
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 somet
--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 <[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
> e
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 s
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 cov
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 l
--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 s
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 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 str
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 bas
--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
--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.
T
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
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
25 matches
Mail list logo
