RE: [HACKERS] SELECT FOR UPDATE in (PL/pgSQL) function

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: RE: [HACKERS] SELECT FOR UPDATE in (PL/pgSQL) function
Date: 1999-07-28 02:58:42
Message-ID: 000101bed8a5$196b04c0$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> Is't possible to use SELECT FOR UPDATE in functions ?
> I have function for 'insert or update' which works ok, but as I have some
> problem with duplicated records I tried as suggested by Tom Lane to use
> SELECT FOR UPDATE instead of just select. Unfortunately it doesn't works:
>
> ERROR: query didn't return correct # of attributes for *internal*
>

AFAIC,"SELECT FOR UPDATE" always causes above errors in
PL/pgSQL functions.
Could we use PL/pgSQL for update procedures in MVCC ?

ORDER/GROUP BY items that are not in the targetlist also cause
same errors in PL/pgSQL functions.
In both cases,target entries are added which are not wanted in the
final projected tuple(SELECT FOR UPDATE adds "ctid" entry).

In such cases,the # of target entries is different from the # of
final attributes estimated in pl_gram.y and above elog() in
pl_exec.c is called.

Should current check be loosen ?
Or another check is necessary ?

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Robinson 1999-07-28 03:00:13 Re: [HACKERS] UPDATE performance degradation (6.5.1)
Previous Message Bruce Momjian 1999-07-28 02:35:09 Re: [HACKERS] Bug tracking system policy