On Wed, 21 Jan 2004, Harald Fuchs wrote:
> In article <[EMAIL PROTECTED]>,
> Richard Huxton <[EMAIL PROTECTED]> writes:
>
> > On Tuesday 20 January 2004 16:42, Tom Lane wrote:
> >> Harald Fuchs <[EMAIL PROTECTED]> writes:
> >> > Why? If the underlying table has a primary key, finding correspondin
On Tuesday 20 January 2004 16:42, Tom Lane wrote:
> Harald Fuchs <[EMAIL PROTECTED]> writes:
> > Why? If the underlying table has a primary key, finding corresponding
> > pairs is trivial; if there isn't, it's impossible.
>
> Exactly. Nonetheless, the correspondence exists --- the UPDATE
> defini
Harald Fuchs <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I'm not very clear on
>> how that works myself --- in particular, one would think it important to
>> be able to work with corresponding pairs of OLD and NEW rows, which
>> would be painful with a table-like abstracti
On Tue, 20 Jan 2004, Harald Fuchs wrote:
> In article <[EMAIL PROTECTED]>,
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Richard Huxton <[EMAIL PROTECTED]> writes:
> >> On Tuesday 20 January 2004 00:01, Neil Conway wrote:
> >>> Yeah, I didn't get around to implementing that. If anyone wants this
>
Richard Huxton <[EMAIL PROTECTED]> writes:
> On Tuesday 20 January 2004 00:01, Neil Conway wrote:
>> Yeah, I didn't get around to implementing that. If anyone wants this
>> feature, I'd encourage them to step up to the plate -- I'm not sure
>> when I'll get the opportunity/motivation to implement t
Richard Huxton <[EMAIL PROTECTED]> writes:
> I didn't think they'd be meaningful for a statement-level
> trigger. Surely OLD/NEW are by definition row-level details.
Granted; the feature in question is *some* means of accessing the
result set of a statement-level trigger -- it probably would not u
On Tuesday 20 January 2004 00:01, Neil Conway wrote:
> Harald Fuchs <[EMAIL PROTECTED]> writes:
> > Does anyone know how to access the affected values for
> > statement-level triggers? I mean what the "old" and "new"
> > pseudo-records are for row-level triggers.
>
> Yeah, I didn't get around to i
Harald Fuchs <[EMAIL PROTECTED]> writes:
> Does anyone know how to access the affected values for
> statement-level triggers? I mean what the "old" and "new"
> pseudo-records are for row-level triggers.
Yeah, I didn't get around to implementing that. If anyone wants this
feature, I'd encourage th
> Exists in pg any way to define the trigger execution only if I have
> changes on some fields?
No, but you chould check for those fields and return if no changes have been
made. Depending on how intensive the trigger is, this might help. You may
also want to look at statement-level triggers or
Guten Tag Richard Huxton,
Am Donnerstag, 15. Januar 2004 um 17:10 schrieben Sie:
RH> On Thursday 15 January 2004 13:13, pginfo wrote:
>> Hi,
>>
>> I am using pg 7.4.1 and have created a trigger over table with 3 M rows.
>> If I start masive update on this table, pg executes this trigger on
>> eve
On Thursday 15 January 2004 13:13, pginfo wrote:
> Hi,
>
> I am using pg 7.4.1 and have created a trigger over table with 3 M rows.
> If I start masive update on this table, pg executes this trigger on
> every row and dramaticaly slows the system.
> Exists in pg any way to define the trigger execut
Hi,
I am using pg 7.4.1 and have created a trigger over table with 3 M rows.
If I start masive update on this table, pg executes this trigger on
every row and dramaticaly slows the system.
Exists in pg any way to define the trigger execution only if I have
changes on some fields?
For example I
12 matches
Mail list logo
