> > It seems to me that there's more and more need for an 'SET CONSTRAINTS
> > DISABLED' and 'SET CONSTRAINTS ENABLED' command that affects
> only foreign
> > keys.
>
> I really dislike the idea of referring to "constraints" but only affecting
> foreign key constraints.
All the other SET CONSTRAI
On Mon, May 13, 2002 at 10:17:07AM +0800, Christopher Kings-Lynne wrote:
> > I'm happy w/o the FORCE option (just let TRUNCATE do it), but if enough
> > people think that the FORCE keyword should be added to allow overriding of
> > triggers, that could be a good compromise.
> >
> > But, please, do
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 12, 2002 10:17 PM
> To: Joel Burton; Tom Lane; Rod Taylor
> Cc: Hackers List
> Subject: RE: [HACKERS] TRUNCATE
>
>
> > I'm happy w/o the FORCE option (just let TRUNCATE do it), but if enough
> >From my limited understanding of truncate in Oracle is it requires the
> user to first disable integrity constraints on the table before
> truncate will run.
>
> In SQL Server that truncate will not allow truncate if foreign key
> constraints exist, but does not execute user delete triggers.
>
> I'm happy w/o the FORCE option (just let TRUNCATE do it), but if enough
> people think that the FORCE keyword should be added to allow overriding of
> triggers, that could be a good compromise.
>
> But, please, don't take away the ability to TRUNCATE. Doing it when there
> are triggers is one th
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > Looks like CommentOperator goes to quite a bit of work (5 lines)
to
> > accomplish fetching the procedure and states specifically it's not
a
> > bug.
>
> I can see the value in having the function comment shown when there
is
> no comment specifically
Tom Lane wrote:
>
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > A *stack* of _active_ transaction numbers is not sufficient, we need
> > the whole *tree* of _all_ transactions belonging to the current top
> > level transaction. This is, want I wanted to model in my pg_subtrans
> > "table". An
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Looks like CommentOperator goes to quite a bit of work (5 lines) to
> accomplish fetching the procedure and states specifically it's not a
> bug.
Yeah, someone once thought it was a good idea, but I was wondering about
the wisdom of it just the other day
Indeed...
Comment on operator adds the comment to the procedures, and drop
operator removes comments from pg_operator, leaving left over entries
in pg_description.
Looks like CommentOperator goes to quite a bit of work (5 lines) to
accomplish fetching the procedure and states specifically it's n
>From my limited understanding of truncate in Oracle is it requires the
user to first disable integrity constraints on the table before
truncate will run.
In SQL Server that truncate will not allow truncate if foreign key
constraints exist, but does not execute user delete triggers.
Can't rememb
During some testing of pgAdmin's internals whilst adding schema support
I noticed that altering or setting a comment on an operator actually
sets the comment on the operator function.
In other words, change the comment on testschema.+(int4, int4) and the
comment is actually set on the function pg
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
> Sent: Sunday, May 12, 2002 12:30 PM
> To: Rod Taylor
> Cc: Hackers List
> Subject: Re: [HACKERS] TRUNCATE
>
>
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > I'm thinking it should check for a
On Thu, May 02, 2002 at 01:14:34PM -0300, Marc G. Fournier wrote:
> On 2 May 2002, Hannu Krosing wrote:
...
> > BTW, I think PostgreSQL does _not_ need any mission statement.
>
> Nope, it doesn't ... never did before, don't know why it does suddenly ...
> do any other open source projects have on
On Sun, 12 May 2002, Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > A *stack* of _active_ transaction numbers is not sufficient, we need
> > the whole *tree* of _all_ transactions belonging to the current top
> > level transaction. This is, want I wanted to model in my pg_subt
The only time I can think of that a FORCE type mechanism would be
allowed would be internal functions. Perhaps a new cluster (copy
data, truncate table, copy data back sorted).
Internal stuff can call heap_truncate() directly rather than going
through TruncateRelation.
A user style force is to
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> I'm thinking it should check for an on delete rule as well as user
> triggers.
Seems reasonable to me.
Should there be a "FORCE" option to override these checks and do it
anyway? Or is that just asking for trouble?
regards, tom
>
> See contrib/dblink. The version in cvs HEAD has two that return sets --
> dblink() which returns an int, and dblink_get_pkey() which returns text.
Thanks, now I can see what I was doing wrong
Yours
Ian Barwick
---(end of broadcast)---
TIP 4
For my own protection I'm adding checks to truncate so that if there
is an ON DELETE trigger it will not execute the truncate command.
Anyway, should it really only be 'Disallow TRUNCATE on tables that are
involved in referential constraints'?
I'm thinking it should check for an on delete rule a
Tom Lane writes:
> In practice we could perhaps use test data that doesn't hit any of the
> special cases in the popular languages. But I wonder whether this would
> not be shirking our responsibility as testers. Seems like if you avoid
> exercising these kinds of cases, you avoid finding corne
Joe Conway <[EMAIL PROTECTED]> writes:
> Actually I found late last night that when the view is used, the RTE is
> a RangeVar, so the RangeFunction code never gets executed. So I think
> your comment above is right on. That may well explain both problems.
Hmm. I thought your view problems wer
Manfred Koizar <[EMAIL PROTECTED]> writes:
> A *stack* of _active_ transaction numbers is not sufficient, we need
> the whole *tree* of _all_ transactions belonging to the current top
> level transaction. This is, want I wanted to model in my pg_subtrans
> "table". And pg_subtrans cannot be a pr
Joel,
On Fri, May 10, 2002 at 12:43:16PM -0400, Joel Burton wrote:
> > > Sorry, but since I install all Cygwin packages plus about 30
> > > additional ones I haven't desire to determine what are the
> > > minimal requirements.
>
> If no one else has done this, I'll be happy to dig in and answer
22 matches
Mail list logo
