Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Is threre any reason not to support "CREATE OR REPLACE"
>> only for triggers?
> Because the oid of a trigger doesn't matter. You can go being; drop
> trigger; create trigger; commit; atomically.
And how often do you need to redefine a trigg
A few days ago, I found that "CREATE OR REPLACE TRIGGER"
is not allowed on 7.4.2. However, functions and rules allow
"CREATE OR REPLACE" statement.
Is threre any reason not to support "CREATE OR REPLACE"
only for triggers?
Because the oid of a trigger doesn't matter. You can go being; drop
trigg
On Mon, 2004-09-13 at 10:52, Satoshi Nagayasu wrote:
> A few days ago, I found that "CREATE OR REPLACE TRIGGER"
> is not allowed on 7.4.2. However, functions and rules allow
> "CREATE OR REPLACE" statement.
> Is threre any reason not to support "CREATE OR REPLACE"
> only for triggers?
And while w
Hello all,
A few days ago, I found that "CREATE OR REPLACE TRIGGER"
is not allowed on 7.4.2. However, functions and rules allow
"CREATE OR REPLACE" statement.
Is threre any reason not to support "CREATE OR REPLACE"
only for triggers?
Thanks.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
OpenSource D
OK, it never removed braces from things like:
int x;
{
int x;
x=5;
}
but anyway I think we all agree it was uglifying the code more than it
was clarifying.
---
Gaeta
I wrote:
> We could revert to Alvaro's initial design in which subxacts didn't take
> out separate locks on their XIDs; this would make XactLockTableWait a
> lot slower though, and probably subject to unwanted deadlocks. You
> really want to release waiters for a subxact as soon as the subxact
> f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|>>I had that argument a while ago with Bruce and lost :-) . It does horrible
|>>things to if/else constructs too. The workaround is to put a comment in the
|>>block. On the whole I agree with you, though.
Daniel Schuchardt <[EMAIL PROTECTED]> writes:
> now I get
> ERROR: buffer XYZ is not owned by resource owner TopTransaction
Yeah, I ran into that earlier today while trying to reproduce your
problem. It's fixed by this pending patch. I didn't see any freeze-up
of the system after running out of
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Well, yes, it has to take a lock on the subtransaction XID, which will
>> be held until main transaction commit. I'm not sure we have much of a
>> choice about this --- although it does seem annoying to have a
>> shared-memory-size constraint on how man
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have removed the code from pgindent. Now how do we clean up the
> try/catch code that got messed up?
I've hand-restored the cases that are in the files I'm currently
editing. I'll look for more later.
regards, tom lane
-
Please submit any improvements you can. It certainly needs attention!
I think it is inconsistent in using oid for lookup. It was originally
written before relfilenode existed (hence the name _oid_2name, while it
should be relfilenode to name or something. Maybe when we move it to
scripts we c
Tom Lane wrote:
> Daniel Schuchardt <[EMAIL PROTECTED]> writes:
> > houres later I'v located the problem. Its not heavy load but
> > subtransactions in Triggers. It's very easy to recreate:
>
> > the problem is this Syntax :
>
> > CREATE OR REPLACE FUNCTION do_standard_mgc() RETURNS TRIGGER AS'
Hackers,
I am in the process of fixing the oid2name contrib module. It needs a
lot of care and feeding. Hopefully for the next release we can move it
to src/bin/scripts so it can use the routines that are in common.c, and
some of the ugliness can go.
I think it will stay in contrib for 8.0 howe
Andrew Dunstan wrote:
> I had that argument a while ago with Bruce and lost :-) . It does horrible
> things to if/else constructs too. The workaround is to put a comment in the
> block. On the whole I agree with you, though. If I put braces in my program
> it's for a reason, and the indenter should
Peter Eisentraut wrote:
Joe Conway wrote:
Perhaps. The first error message seems clear enough to me, but if you
want to send me the necessary distutils test, I can incorporate it.
Any other opinions out there?
It looks like a waste of space and time to me.
Are you serious ? May you quantify the
Joe Conway wrote:
> Perhaps. The first error message seems clear enough to me, but if you
> want to send me the necessary distutils test, I can incorporate it.
> Any other opinions out there?
It looks like a waste of space and time to me. We can't really check
for everything, let alone precondit
Andrew Dunstan wrote:
Tom Lane said:
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
Hi all,
one year ago I did this post:
http://archives.postgresql.org/pgsql-admin/2003-04/msg00137.php
however I had no reply att all, do you know why there is not a
concept of: "security definer" on views too ?
If in that post I was not clear please let me know.
Regards
Gaetano Mendola
---
Tom Lane said:
> I'm fairly displeased with what pgindent has done to single-line PG_TRY
> constructs, as in this example from pl_exec.c:
>
> *** exec_stmt_block(PLpgSQL_execstate * esta
> *** 911,922
> SPI_result_code_string(xrc));
>
>
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
PG_TRY();
!
Daniel Schuchardt <[EMAIL PROTECTED]> writes:
> houres later I'v located the problem. Its not heavy load but
> subtransactions in Triggers. It's very easy to recreate:
> the problem is this Syntax :
> CREATE OR REPLACE FUNCTION do_standard_mgc() RETURNS TRIGGER AS'
> BEGIN
>BEGIN
> --
On Sat, 11 Sep 2004, Tiago Wright wrote:
IMHO, it is worth duplicating the mvcc data to all index entries. To
summarize what I understand from this discussion, with the current
method:
a1 - Index seeks must return invisible tuples because mvcc data is not
found in the index. These tuples are elimin
On Friday 10 September 2004 17:58, Bruce Momjian wrote:
> Devrim GUNDUZ wrote:
> > Hi,
> >
> > AFAIR there was a thread about "SELECT FOR UPDATE NOWAIT" availability in
> > {7.5,8.0}, 7-8 months ago.
> >
> > Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
> > SELECT ... NOWAI
On Sat, 11 Sep 2004, Daniel Schuchardt wrote:
> Hi list,
>
> is it is known that postgres 8.0 (beta1 and beta2 both same behavoir)
> will eat tons of memory on Windows under heavy load?
I do not believe that this is known.
>
> Scenario:
>
> I have a big delete with about 56000 rows. (DELETE FROM
24 matches
Mail list logo
