My first idea when this was mentioned was more like
ALTER TABLE CASCADE
where CASCADE meant recompile all the views that depend on that table.
Not that I think any of this is a good idea, but if it was going to be
done, that's what would make the most sense to me.
- Ian
-
William Yu <[EMAIL PROTECTED]> writes:
> Chris Browne wrote:
>> I'm pretty sure that they _don't_ track balance updates for each
>> transaction that applies to a customer's account. You could, via one
>> form of trickery or another, "overdraw" your account by a fairly hefty
>> amount, and they pro
On Sun, Aug 28, 2005 at 08:46:56 +0800,
Tang Tim Hei <[EMAIL PROTECTED]> wrote:
>
> In the above command, I just add another table reference to it and it gives
> me two different results.
> Even I add columns like B.* to it, it do the same things too. Is it not
> consistance?
> In real world
On Sun, 28 Aug 2005, Tang Tim Hei wrote:
>
> >
> > ?H: Stephan Szabo <[EMAIL PROTECTED]>
> > : 2005/08/27 ?P ?U?? 11:25:49 HKT
> > ??: Tang Tim Hei <[EMAIL PROTECTED]>
> > : pgsql-general@postgresql.org
> > ?D??: Re: [GENERAL] A strange problem
> >
> > On Sat, 27 Aug 2005, Tang
>
> 寄件者: Stephan Szabo <[EMAIL PROTECTED]>
> 日期: 2005/08/27 星期六 下午 11:25:49 HKT
> 收件者: Tang Tim Hei <[EMAIL PROTECTED]>
> 副本: pgsql-general@postgresql.org
> 主旨: Re: [GENERAL] A strange problem
>
> On Sat, 27 Aug 2005, Tang Tim Hei wrote:
>
> > Hi,
>
> > I'm new to postgresql. Anytime I type
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
How is this different from materialized views, which is already on the
TODO list?
The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
table it could be refl
On Sat, Aug 27, 2005 at 11:08:26AM -0700, Simrin Grewal wrote:
> I have a table that has an update rule and an after insert trigger on
> it. The rule checks to see if certain things happened during the update
> and goes and does another insert to a secondary table. The trigger is
> an after in
Martijn van Oosterhout writes:
> There's a lot of discussion about this, yet no-one has demonstrated that
> COPY FROM STDIN isn't just as good and avoids all the issues entirely.
In any case here's some quick results from my system. There seems to a greater
than 21% slowdown associated with pipi
Mike Nolan <[EMAIL PROTECTED]> writes:
> The notes on participating in the 8.1 beta suggest creating a dump using
> both an old and new copy of pg_dump.
> Does this mean we can't use pg_dumpall or that we have to restore both
> dumps? (Or is that just a way of testing what works and what doesn'
Martijn van Oosterhout writes:
> On Sat, Aug 27, 2005 at 01:20:29AM -0400, Greg Stark wrote:
> > For that matter it might be handy to be able to grant permission to regular
> > users to load or dump files to arbitrary locations. The security
> > consequences
> > would have to be documented but I
Tom Lane <[EMAIL PROTECTED]> writes:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> How is this different from materialized views, which is already on the
> >> TODO list?
>
> > The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
> > table it could be reflected in the view.
Our own personal IM :)
Chris Travers wrote:
The delay will by definition defeat any guarantee of financial integrity
if you are allowing read-write operations to the replica without
checking with some sort of central authority. At very least, the
central authority should look for suspicious p
The notes on participating in the 8.1 beta suggest creating a dump using
both an old and new copy of pg_dump.
Does this mean we can't use pg_dumpall or that we have to restore both
dumps? (Or is that just a way of testing what works and what doesn't
between older dump files and the beta release
Bruce Momjian writes:
> Well, I just added to TODO:
>
> * Allow VIEW/RULE recompilation when the underlying tables change
>
> Is dynamic view a industry-standard name? If so, I will add it to the
> TODO.
"DYNAMIC" is something I made up.
"ALTER VIEW RECOMPILE" is Oraclese but I'm not s
Hey Folks,
Scratching my head on this one wanted to know if anyone else had
encounter it.
I have a table that has an update rule and an after insert trigger on
it. The rule checks to see if certain things happened during the update
and goes and does another insert to a secondary table. The
William Yu wrote:
Chris Travers wrote:
1) Efficiency of network throughput
2) Tolerance to attempts at repeat transactions before replication
(emptying an account multiple times)
3) Availability of a transaction.
We ended up having to give up #1. It's possible to have our
transactions
Tom Lane wrote:
But why exactly is this a good idea?
Especially since it seems one could write PLPGSQL functions to emulate
this if it was so important. The lack of PLPGSQL functions to do this
seems to indicate that it is not worth the trouble,
It is oft-repeated advice that you don't
Tang Tim Hei <[EMAIL PROTECTED]> writes:
> Hi,
> I'm new to postgresql. Anytime I type the following command to the database
> to run, it give me no result record if table 'country' is empty but can get
> result if 'country' is not empty. Is this so strange?
>
> select A.* from test.currency
On Sat, 27 Aug 2005, Tang Tim Hei wrote:
> Hi,
> I'm new to postgresql. Anytime I type the following command to the
> database to run, it give me no result record if table 'country' is
> empty but can get result if 'country' is not empty. Is this so
> strange?
Not really. You're doing a
Hi,
I'm new to postgresql. Anytime I type the following command to the database
to run, it give me no result record if table 'country' is empty but can get
result if 'country' is not empty. Is this so strange?
select A.* from test.currency A, test.country B where A.curr_cd='USD'
--
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> How is this different from materialized views, which is already on the
>> TODO list?
> The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
> table it could be reflected in the view. So for example, if you defined
> a view as SELECT
pgman wrote:
> Tony Caduto wrote:
> > Hi Bruce,
> > That would be great :-) Thank you very much.
> >
> > I will keep the author information etc intact.
>
> Sure, I put them at:
>
> http://candle.pha.pa.us/cookbook/
>
> I will keep them online for 2 weeks.
I also created a tarball:
Tony Caduto wrote:
> Hi Bruce,
> That would be great :-) Thank you very much.
>
> I will keep the author information etc intact.
Sure, I put them at:
http://candle.pha.pa.us/cookbook/
I will keep them online for 2 weeks.
--
Bruce Momjian| http://candle.pha.
On Sat, Aug 27, 2005 at 18:19:54 +0530,
sunil arora <[EMAIL PROTECTED]> wrote:
> Bruno,
> thanks for the reply,
> we did run vaccum on it.. and we do it regulary to maintain its
> performance but its not giving the expected results.
Did you do VACUUM FULL or just plain VACUUM?
> I dont know but
Well, I just added to TODO:
* Allow VIEW/RULE recompilation when the underlying tables change
Is dynamic view a industry-standard name? If so, I will add it to the
TODO.
Updated TODO is:
* Allow VIEW/RULE recompilation when the underlying tables change
Chris Travers wrote:
1) Efficiency of network throughput
2) Tolerance to attempts at repeat transactions before replication
(emptying an account multiple times)
3) Availability of a transaction.
We ended up having to give up #1. It's possible to have our transactions
routed to multiple se
Bruno,
thanks for the reply,
we did run vaccum on it.. and we do it regulary to maintain its
performance but its not giving the expected results.
I dont know but if we delete the entire database and restore it with
the dump, then things seems to improve a _LOT_.
Isnt vaccum suppose to do the same
On Sat, Aug 27, 2005 at 01:20:29AM -0400, Greg Stark wrote:
> > Of course that method only applies to a subset of PG users, and
> > completely excludes the Windows side. It might also conflict with
> > security policies that forbid PG from reading and writing outside its
> > own data directory.
>
am 26.08.2005, um 2:11:30 +0430 mailte Lee Harr folgendes:
> >I have not been able to work out how to do this is Postgres 8
> >(pseudo-code)
> > if exists table foo
> > drop table foo;
> > end
> > create table foo;
> >If I go with
> > drop table foo;
> > create table foo;
> >then it barfs on
Bruce Momjian writes:
> How is this different from materialized views, which is already on the
> TODO list?
It's entirely unrelated.
Materialized views are about having all the data stored in advance. They're
really tables that have some sort of process to keep the data in them in sync
with ot
30 matches
Mail list logo
