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
