On 2017/06/21 18:49, Dean Rasheed wrote:
> On 20 June 2017 at 03:01, Amit Langote wrote:
>> Hmm, yes. The following exercise convinced me.
>>
>> create table r (a int) partition by range (a);
>> create table r1 partition of r for values from (1) to (10);
>> create rule "_RETURN" as on select to r
On 20 June 2017 at 03:01, Amit Langote wrote:
> Hmm, yes. The following exercise convinced me.
>
> create table r (a int) partition by range (a);
> create table r1 partition of r for values from (1) to (10);
> create rule "_RETURN" as on select to r1 do instead select * from r;
>
> insert into r
On 2017/06/20 17:51, Dean Rasheed wrote:
> On 20 June 2017 at 03:01, Amit Langote wrote:
>> On 2017/06/19 20:19, Dean Rasheed wrote:
>>> Perhaps we
>>> should explicitly forbid this for now -- i.e., raise a "not supported"
>>> error when attempting to add a rule to a partition, or attach a table
>
On 20 June 2017 at 03:01, Amit Langote wrote:
> On 2017/06/19 20:19, Dean Rasheed wrote:
>> Currently we allow rules to be defined on table partitions, but these
>> rules only fire when the partition is accessed directly, not when it
>> is accessed via the parent:
>
> Yeah, the same thing as will
Hi Dean,
On 2017/06/19 20:19, Dean Rasheed wrote:
> Currently we allow rules to be defined on table partitions, but these
> rules only fire when the partition is accessed directly, not when it
> is accessed via the parent:
Yeah, the same thing as will happen with an inheritance setup, but I guess
On 6/19/17 07:19, Dean Rasheed wrote:
> Currently we allow rules to be defined on table partitions, but these
> rules only fire when the partition is accessed directly, not when it
> is accessed via the parent
That's what I would have expected, but I realize that there are always
multiple ways to
Currently we allow rules to be defined on table partitions, but these
rules only fire when the partition is accessed directly, not when it
is accessed via the parent:
CREATE TABLE t1(a int, b int) PARTITION BY RANGE(a);
CREATE TABLE t1_p PARTITION OF t1 FOR VALUES FROM (1) TO (10);
INSERT INTO t1
On Sun, Aug 19, 2012 at 12:06:30PM -0400, Tom Lane wrote:
> While thinking about this I wondered whether it might be possible to
> clean up the implementation of rules, and perhaps also get rid of some
> of their semantic issues, by making the rule rewriter rely on WITH
> and/or LATERAL, neither of
Six years ago, we punted on allowing rules to use OLD and NEW in
multi-row VALUES constructs, because we didn't have LATERAL:
http://archives.postgresql.org/pgsql-hackers/2006-08/msg00044.php
I thought maybe that restriction could be fixed now that we do have
LATERAL, and indeed the attached quick
On Fri, Mar 9, 2012 at 2:14 PM, Tom Lane wrote:
> I'm inclined to only fix this in HEAD.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
I looked into the misbehavior reported here:
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00068.php
The reason the ALTER TABLE fails to fail is $SUBJECT: it goes looking
for pg_depend entries showing that rewrite rules depend on the column to
be altered, but there isn't one. This is basic
sfr...@snowman.net (Stephen Frost) writes:
> * David Fetter (da...@fetter.org) wrote:
>> On Sun, Oct 04, 2009 at 04:07:40PM -0400, Robert Haas wrote:
>> > > The radical proposal was the RULE system. It's been tested now,
>> > > and it's pretty much failed.
>> >
>> > You still haven't explained w
On Mon, Oct 5, 2009 at 10:17 AM, Josh Berkus wrote:
> So while rules are hard to use and easy to mess up, so are triggers. So
> while an (arguable) problem is being pointed out, no real solution is
> being proposed.
If you want to implement updatable views I still stand by my (much)
earlier desi
> "Josh" == Josh Berkus writes:
>> 1) any reference in an insert rule to NEW.col where col has a volatile
>> default, or the expression in the insert statement was volatile, or
>> the expression's value is changed by the insert, will do the wrong
>> thing:
Josh> Is this different from t
Andrew,
> 1) any reference in an insert rule to NEW.col where col has a volatile
>default, or the expression in the insert statement was volatile, or
>the expression's value is changed by the insert, will do the wrong
>thing:
Is this different from triggers?
> 2) any rule with multip
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> >Stephen Frost wrote:
> > Do we have a patch which implements the necessary mechanics to
> > replace RULEs, even for the specific situations you list? Until
> > then, I don't think there's much to discuss.
>
> I thought that until we had d
>Stephen Frost wrote:
> Do we have a patch which implements the necessary mechanics to
> replace RULEs, even for the specific situations you list? Until
> then, I don't think there's much to discuss.
I thought that until we had discussion and consensus it was premature
to start working on a p
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
> Dan Colish wrote:
> > On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> > > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
>
> > > > You can definitely create updatable views using rules.
> > >
> > > Sure y
2009/10/5 Dan Colish :
> On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
>> Dan Colish wrote:
>> > On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
>> > > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
>>
>> > > > You can definitely create updatable views usi
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
> Dan Colish wrote:
> > On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> > > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
>
> > > > You can definitely create updatable views using rules.
> > >
> > > Sure y
Dan Colish wrote:
> On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> > On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
> > > You can definitely create updatable views using rules.
> >
> > Sure you can, but they won't work in various significant corner cases.
> >
> > Sear
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
> On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
> > I am not sure where that view implemenation is, but I doubt its
> > stalled because of the rule system.
>
> It is.
>
> > You can definitely create updatable views using ru
On Mon, Oct 05, 2009 at 10:32:53AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > WITH NEW AS (
> > insert into t values (floor(random()*1000)::integer);
> > RETURNING *
> > )
> > insert into t_log values (NEW.a);
>
> > Would this not have the required semantics?
>
> Interestin
Martijn van Oosterhout writes:
> ISTM it may be possible to use the new WITH construct here. So the rule
> evaluation for the following
>> create table t (a integer);
>> create table t_log (a integer);
>> create rule t_ins AS ON insert TO t do also insert into t_log values (NEW.a);
>> insert into
On Mon, Oct 05, 2009 at 02:53:56PM +0100, Andrew Gierth wrote:
> Here are a couple of the more common ones:
>
> 1) any reference in an insert rule to NEW.col where col has a volatile
>default, or the expression in the insert statement was volatile, or
>the expression's value is changed by
> "Greg" == "Greg Sabino Mullane" writes:
>> They're mostly a foot-gun.
Greg> Lots of things in Postgres could be considered potential foot
Greg> guns. Frankly, I don't think rules are even near the top of
Greg> such a list. Can you give examples of rule foot guns?
There are so many it'
Greg Sabino Mullane wrote:
> Could this be done with a trigger? Yes, but on the plus rules side:
>
> * It's faster
> * It's easier to write
> * It's immediately viewable as to what is going on with a \d mytable
> * Dropping it won't leave an unused function around
> * We can still do ALTER TABLE D
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> At the moment, user-accessible RULEs have, as far as I know,
> just two sane uses:
>
--On 4. Oktober 2009 21:37:45 -0400 Robert Haas
wrote:
This is the last I remember hearing of it, which seems to suggest that
only a week's worth of work (maybe a bit more for those of us who are
not Tom Lane) is needed:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php
Bu
--On 5. Oktober 2009 09:51:29 +0300 Peter Eisentraut
wrote:
The way forward with updatable views is triggers on views. I was going
to write something about that in the future. I haven't worked out all
the details.
In the mentioned discussion there was already the notion of "substitution
On Sun, 2009-10-04 at 20:54 -0400, Alvaro Herrera wrote:
> While I don't agree with David Fetter's premise, I think rehashing how
> we handle VIEWs would be a good step towards updatable views. Right
> now, the implementation of that is stalled precisely because of the rule
> system.
The way forw
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
> I am not sure where that view implemenation is, but I doubt its
> stalled because of the rule system.
It is.
> You can definitely create updatable views using rules.
Sure you can, but they won't work in various significant corner cases.
Se
On Sun, Oct 4, 2009 at 10:01 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> > While I don't agree with David Fetter's premise, I think rehashing how
>> > we handle VIEWs would be a good step towards updatable views. Right
>> > now, the implementation of that is stalled precisely because o
Robert Haas escribió:
> > While I don't agree with David Fetter's premise, I think rehashing how
> > we handle VIEWs would be a good step towards updatable views. Right
> > now, the implementation of that is stalled precisely because of the rule
> > system.
>
> This is the last I remember hearin
On Sun, Oct 4, 2009 at 8:54 PM, Alvaro Herrera
wrote:
> David E. Wheeler wrote:
>> On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
>>
>> >It's less about like or dislike and more about facing up to the
>> >reality that we've got a major legacy foot-gun left over from the
>> >experimentation of the
On Sun, Oct 04, 2009 at 08:54:56PM -0400, Alvaro Herrera wrote:
> David E. Wheeler wrote:
> > On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
> >
> > >It's less about like or dislike and more about facing up to the
> > >reality that we've got a major legacy foot-gun left over from the
> > >experim
David E. Wheeler wrote:
> On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
>
> >It's less about like or dislike and more about facing up to the
> >reality that we've got a major legacy foot-gun left over from the
> >experimentation of the Berkeley days.
>
> I think you're going to need to be a bit
On Sun, Oct 4, 2009 at 6:42 PM, David Fetter wrote:
>> I agree that rules, except for SELECT rules, don't seem to be very
>> useful. Perhaps others have found them so, but I have found
>> triggers to be a better fit for everything that I ever want to do.
>> Every time I think, hmm, maybe I could
On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
It's less about like or dislike and more about facing up to the
reality that we've got a major legacy foot-gun left over from the
experimentation of the Berkeley days.
I think you're going to need to be a bit more concrete than that. In
what wa
On Sun, October 4, 2009 1:48 pm, Pavel Stehule wrote:
> 2009/10/4 David Fetter :
>> Folks,
>>
>> At the moment, user-accessible RULEs have, as far as I know, just two
>> sane uses:
>>
>> * Writing to VIEWs
>> * Routing writes to partitions
>
> somebody use it as instead triggers. And I am sure, so
* David Fetter (da...@fetter.org) wrote:
> On Sun, Oct 04, 2009 at 04:07:40PM -0400, Robert Haas wrote:
> > > The radical proposal was the RULE system. It's been tested now,
> > > and it's pretty much failed.
> >
> > You still haven't explained what actual benefit we'd get out of
> > doing this.
On Sun, Oct 04, 2009 at 04:07:40PM -0400, Robert Haas wrote:
> On Sun, Oct 4, 2009 at 3:34 PM, David Fetter wrote:
> >> What would be the benefit of this radical proposal?
> >
> > The radical proposal was the RULE system. It's been tested now,
> > and it's pretty much failed.
>
> You still haven
On Sun, Oct 04, 2009 at 01:25:31PM -0700, Josh Berkus wrote:
> David,
>
> > The radical proposal was the RULE system. It's been tested now,
> > and it's pretty much failed.
>
> I don't think you've demonstrated that. I know *you* don't like
> RULEs, but others do.
It's less about like or disli
David,
> The radical proposal was the RULE system. It's been tested now, and
> it's pretty much failed.
I don't think you've demonstrated that. I know *you* don't like RULEs,
but others do. I could propose that UUIDs are a bankrupt concept (which
I believe) and therefore we should drop the UUI
2009/10/4 David Fetter :
> On Sun, Oct 04, 2009 at 08:48:15PM +0200, Pavel Stehule wrote:
>> 2009/10/4 David Fetter :
>> > Folks,
>> >
>> > At the moment, user-accessible RULEs have, as far as I know, just two
>> > sane uses:
>> >
>> > * Writing to VIEWs
>> > * Routing writes to partitions
>>
>> so
On Sun, Oct 4, 2009 at 3:34 PM, David Fetter wrote:
>> What would be the benefit of this radical proposal?
>
> The radical proposal was the RULE system. It's been tested now, and
> it's pretty much failed.
You still haven't explained what actual benefit we'd get out of doing this.
I agree that
On Sun, Oct 04, 2009 at 11:42:45AM -0700, Josh Berkus wrote:
> > There are already patches to deal with the first, at least for the
> > kinds of VIEWs where this can be deduced automatically, and people
> > are starting to take on the second.
>
> How would we deal with VIEWs which weren't simple e
On Sun, Oct 04, 2009 at 03:15:10PM -0400, Andrew Dunstan wrote:
>
>
> Dan Colish wrote:
> >When you speak of writing to a view, what do you mean exactly? Are we saying
> >refresh a view or update the parent tables of a view?
> >
> >
>
> He means INSERT, UPDATE and DELETE operations on the view.
On Sun, Oct 04, 2009 at 08:48:15PM +0200, Pavel Stehule wrote:
> 2009/10/4 David Fetter :
> > Folks,
> >
> > At the moment, user-accessible RULEs have, as far as I know, just two
> > sane uses:
> >
> > * Writing to VIEWs
> > * Routing writes to partitions
>
> somebody use it as instead triggers.
Dan Colish wrote:
When you speak of writing to a view, what do you mean exactly? Are we saying
refresh a view or update the parent tables of a view?
He means INSERT, UPDATE and DELETE operations on the view.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On Sun, Oct 04, 2009 at 11:42:45AM -0700, Josh Berkus wrote:
>
> > There are already patches to deal with the first, at least for the
> > kinds of VIEWs where this can be deduced automatically, and people are
> > starting to take on the second.
>
> How would we deal with VIEWs which weren't simpl
> There are already patches to deal with the first, at least for the
> kinds of VIEWs where this can be deduced automatically, and people are
> starting to take on the second.
How would we deal with VIEWs which weren't simple enough for automated
updating, then?
I don't think that removing a maj
2009/10/4 David Fetter :
> Folks,
>
> At the moment, user-accessible RULEs have, as far as I know, just two
> sane uses:
>
> * Writing to VIEWs
> * Routing writes to partitions
somebody use it as instead triggers. And I am sure, so there are
people, who use it for writable views.
regards
Pavel St
Folks,
At the moment, user-accessible RULEs have, as far as I know, just two
sane uses:
* Writing to VIEWs
* Routing writes to partitions
And the second is pretty thin, given the performance issues for
numbers of partitions over 2.
What say we see about addressing those problems separately, and
DML rules don't work during read only transactions. Now that is a real
shame because it would allow some important capabilities when running in
Hot Standby mode.
postgres=# create or replace function foo () returns void
language plpgsql as
$$ begin null; end; $$;
CREATE FUNCTION
postgres=# crea
On Mon, Dec 15, 2008 at 11:27 AM, Tom Lane wrote:
> I wrote:
>> But I don't see this sorting behavior with glibc on Linux (Fedora 9 to
>> be exact, testing LC_COLLATE=es_ES.utf8).
>
doh! i'm seeing this again in HEAD (and in 8.3.5) when executing make
installcheck on openSuse 11
when initdb'ing
On Mon, Dec 15, 2008 at 10:19 AM, Tom Lane wrote:
>
> Well, one thing you should try is
>
>select 'wieck'::text < 'wiech'::text;
>select 'wieck'::text > 'wiech'::text;
>
administra...@casanova10 ~/pg.build/8.4dev
$ bin/psql -a -f test.sql postgres
select 'wieck'::text < 'wiech'::t
I wrote:
> But I don't see this sorting behavior with glibc on Linux (Fedora 9 to
> be exact, testing LC_COLLATE=es_ES.utf8).
BTW, I *do* see wieck < wiech in es_ES locale on HPUX 10.20, released
~1996. So I think we have correctly identified the core issue, and the
only interesting question is w
Alvaro Herrera writes:
> Jaime Casanova wrote:
>> while 'ch' and 'll' are independent letters they sort as they were 'c'
>> and 'l'... that means that 'ch' should go before 'ck'
> Interesting. So they are both wrong, glibc and teachers. We can file a
> bug with glibc but I'm not sure we can do
Jaime Casanova wrote:
> On Mon, Dec 15, 2008 at 10:26 AM, Alvaro Herrera
> wrote:
> > It was sane behavior a couple of decades ago -- dictionaries used to
> > sort like this ("ch" was considered an independent letter, and sorted
> > between c and d).
>
> while 'ch' and 'll' are independent lette
On Mon, Dec 15, 2008 at 10:26 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> "Jaime Casanova" writes:
>> > On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane wrote:
>> >> What locale is this running in?
>>
>> > Seems this is Spanish_Spain.1252 and the encoding WIN1252
>>
>> What it looks like is that the
Tom Lane wrote:
> "Jaime Casanova" writes:
> > On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane wrote:
> >> What locale is this running in?
>
> > Seems this is Spanish_Spain.1252 and the encoding WIN1252
>
> What it looks like is that the locale is intentionally sorting h after k
> (or more likely the
"Jaime Casanova" writes:
> On Mon, Dec 15, 2008 at 10:12 AM, Tom Lane wrote:
>> What it looks like is that the locale is intentionally sorting h after k
>> (or more likely the rule is ch after ck). My Spanish is just about gone
>> ... is that a sane behavior at all?
> not at all... where can i
On Mon, Dec 15, 2008 at 10:12 AM, Tom Lane wrote:
> What it looks like is that the locale is intentionally sorting h after k
> (or more likely the rule is ch after ck). My Spanish is just about gone
> ... is that a sane behavior at all?
>
not at all... where can i check those rules?
--
Atenta
"Jaime Casanova" writes:
> On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane wrote:
>> What locale is this running in?
> Seems this is Spanish_Spain.1252 and the encoding WIN1252
What it looks like is that the locale is intentionally sorting h after k
(or more likely the rule is ch after ck). My Spani
On Mon, Dec 15, 2008 at 8:59 AM, Tom Lane wrote:
> "Jaime Casanova" writes:
>> i'm seeing a fail in the rules regression, seems like it is not
>> ordering the results right even when the regression has an explicit
>> order by...
>
> What locale is this running in?
>
Seems this is Spanish_Spain.1
"Jaime Casanova" writes:
> i'm seeing a fail in the rules regression, seems like it is not
> ordering the results right even when the regression has an explicit
> order by...
What locale is this running in?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql
Hi,
i'm seeing a fail in the rules regression, seems like it is not
ordering the results right even when the regression has an explicit
order by...
i'm in a mingw32 5.1 on xp sp2 using msys 1.0.10 and gcc 3.4.2
attached the regression.diffs
please make me know if i can provide more info
--
Ate
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Use two tables. One has rules, the other has the trigger. (Neither store
> any data.) Here's a working example (tested on 7.4.5):
> -- declare the table which we're going to be manipulating. This never
> -- actually stores anything (it becomes a vie
On 2004-12-05, elein <[EMAIL PROTECTED]> wrote:
> We're working on DBI-link which is an access method of sorts
> using existing tools.
>
> We want an empty local table foo with
> 1. a _RETURN RULE
> 2. an update TRIGGER
> 3. a delete TRIGGER
> 4. an insert TRIGGER
Use two t
We'd want the tuples to be produced by the select rule
and treated as if we didn't care where they came from.
Perhaps it doesn't work this way because of the way srfs
were integrated into the SQL execution? I dunno.
do instead triggers should be deemed safe on a view
for those brave enough to try
elein <[EMAIL PROTECTED]> writes:
> Also, what are the reasons for forbidding triggers on views?
The fact that they'd never fire (or better never fire). A view does not
actually store any tuples, so update and delete triggers on it are
certainly useless. You could imagine allowing BEFORE INSERT
We're working on DBI-link which is an access method of sorts
using existing tools.
We want an empty local table foo with
1. a _RETURN RULE
2. an update TRIGGER
3. a delete TRIGGER
4. an insert TRIGGER
It seems we can have either the RULE or the TRIGGERs but not bot
Darko Prenosil <[EMAIL PROTECTED]> writes:
> CREATE RULE child_ins AS ON INSERT TO test.child
> DO INSTEAD SELECT test.testfi(NEW);
> INSERT INTO test.child(id,id_data,opis,podaci) VALUES (1,1,'Opis','podaci');
> (-403)ERROR: cannot handle whole-row reference
It works in CVS tip ;-). No
Why is this wrong ?:
DROP SCHEMA test CASCADE ;
CREATE SCHEMA test;
CREATE TABLE test.parent (
id serial PRIMARY KEY,
opis text
);
CREATE TABLE test.child_data (
id serial PRIMARY KEY,
id_parent int ,
podaci text,
FOREIGN KEY (id_parent) REFERENCE
Hello,
I have the following problem. I have a database with different tables. This database is accessed from different users using different logins to access some of the tables.It's not a problem to limit the access of these users to certain tables.They can be included into a group and allowed acce
> Hmm. I think this consideration boils down to whether the WHERE clause
> can give different results for rows that appear equal under the rules of
> UNION/EXCEPT/INTERSECT. If it gives the same result for any two such
> rows, then it's safe to push down; otherwise not.
>
> It's not too diffic
On Thu, 1 Aug 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > So if T1 has a #dups>0 and T2 has a #dups>0 we should get
> > no rows, but what if T1' (with the clause) has a #dups>0 but
> > T2' has a #dups=0?
>
> Um, you're right --- pushing down into the right-hand side wou
Stephan Szabo <[EMAIL PROTECTED]> writes:
> So if T1 has a #dups>0 and T2 has a #dups>0 we should get
> no rows, but what if T1' (with the clause) has a #dups>0 but
> T2' has a #dups=0?
Um, you're right --- pushing down into the right-hand side would reduce
N, thereby possibly *increasing* the nu
On Thu, 1 Aug 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > If we assume two collations one case sensitive one not with the
> > except in the non-sensitive and the where in the sensitive and
> > a left with 'A' and right with 'a', it'd be incorrect to push a
> > case sens
On Thu, 2002-08-01 at 18:02, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > For union, queries that want to do something like use a temporary
> > sequence to act sort of like rownum and do row limiting. Admittedly
> > that's already pretty much unspecified behavior, but it does c
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Actually I think in except you may only push down to the left, since in
> this case you know that any duplicate from the right will not be
> returned (since there must be none). So, you can't potentially drop
> a row from the right side that may have be
On Thu, 1 Aug 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > For union, queries that want to do something like use a temporary
> > sequence to act sort of like rownum and do row limiting. Admittedly
> > that's already pretty much unspecified behavior, but it does change
>
Stephan Szabo <[EMAIL PROTECTED]> writes:
> For union, queries that want to do something like use a temporary
> sequence to act sort of like rownum and do row limiting. Admittedly
> that's already pretty much unspecified behavior, but it does change
> the behavior in the place of duplicate remova
On Thu, 1 Aug 2002, Stephan Szabo wrote:
> On 1 Aug 2002, Hannu Krosing wrote:
>
> > On Thu, 2002-08-01 at 12:29, Curt Sampson wrote:
> > > On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
> > >
> > > > I had a "union all" view, which is actually a quite different animal than
> > > > a "unio
On 1 Aug 2002, Hannu Krosing wrote:
> On Thu, 2002-08-01 at 12:29, Curt Sampson wrote:
> > On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
> >
> > > I had a "union all" view, which is actually a quite different animal than
> > > a "union" view which needs to eliminate duplicates before furth
On Thu, 2002-08-01 at 12:29, Curt Sampson wrote:
> On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
>
> > I had a "union all" view, which is actually a quite different animal than
> > a "union" view which needs to eliminate duplicates before further processing.
>
> I had the same problem wit
On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
> I had a "union all" view, which is actually a quite different animal than
> a "union" view which needs to eliminate duplicates before further processing.
I had the same problem with UNION ALL.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81
> But the message I was replying to was a similar union query, and I was
> thinking that that person might be having a similar initial intuitive
> reaction, "well, it looks kinda the same." I just wanted to note that
> you need to check this stuff with explain, rather than
> blindly assuming
> y
On Thu, 1 Aug 2002, Tom Lane wrote:
> But that isn't an "equivalent query". You've manually transformed
> SELECT * FROM (SELECT something UNION SELECT somethingelse) WHERE foo;
> into
> (SELECT something WHERE foo) UNION (SELECT somethingelse WHERE foo);
Right.
> As has been pointed ou
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Thu, 1 Aug 2002, Tom Lane wrote:
>> Curt Sampson <[EMAIL PROTECTED]> writes:
> You want to be careful with this sort of stuff, since the query planner
> sometimes won't do the view as efficiently as it would do the fully
> specified equivalant query. I
On Thu, 1 Aug 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > You want to be careful with this sort of stuff, since the query planner
> > sometimes won't do the view as efficiently as it would do the fully
> > specified equivalant query. I've posted about this here before.
>
Curt Sampson <[EMAIL PROTECTED]> writes:
> You want to be careful with this sort of stuff, since the query planner
> sometimes won't do the view as efficiently as it would do the fully
> specified equivalant query. I've posted about this here before.
Please provide an example. AFAIK a view is a
On Wed, 31 Jul 2002, Zeugswetter Andreas SB SD wrote:
> The utility is "Table Partitioning by expression".
>
> Basically you have a union view like:
> create view history as
> select * from history2000 where yearcol=2000
> union all
> select * from history2001 where yearcol=2001
You want to be c
> > Since I see a huge benefit in allowing conditional rules for a view,
> > I think it is worth finding a solution.
>
> We do allow conditional rules for a view. You just have to write an
> unconditional one too (which can be merely DO INSTEAD NOTHING).
Hmm, but you cannot then trow an error,
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Since I see a huge benefit in allowing conditional rules for a view,
> I think it is worth finding a solution.
We do allow conditional rules for a view. You just have to write an
unconditional one too (which can be merely DO INSTEAD NOTHI
> > Seems more accurate, but actually you may also have two or more
> > conditional rules that cover all possibilities if taken together.
> > Maybe
> > ERROR: Cannot insert into a view
> > You need an ON INSERT DO INSTEAD rule that matches your INSERT
> > Which covers both cases.
>
> Ac
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2002-07-31 at 10:22, Tom Lane wrote:
>> Hm. How about
>>
>> ERROR: Cannot insert into a view
>> You need an unconditional ON INSERT DO INSTEAD rule
> Seems more accurate, but actually you may also have two or more
> conditional rules that cov
On Wed, 2002-07-31 at 10:22, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > On Wed, 31 Jul 2002, Tom Lane wrote:
> >> Well, to my mind that's what the error message says now. The reason
> >> it didn't help you was that you *did* have a rule ... but it didn't
> >> completely overri
On Wed, 31 Jul 2002, Tom Lane wrote:
> ERROR: Cannot insert into a view
> You need an unconditional ON INSERT DO INSTEAD rule
Sounds great to me!
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light
1 - 100 of 112 matches
Mail list logo
