Re: plpython function problem workaround

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Sim Zacks <sim(at)compulab(dot)co(dot)il>, pgsql-general(at)postgresql(dot)org
Subject: Re: plpython function problem workaround
Date: 2005-03-14 15:54:22
Message-ID: 13832.1110815662@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> Are there any problems with doing this? Is a VALIDATOR function
> permitted to modify the function it's validating?

Well, it's not *supposed* to, but the tuple is already stored so I
guess an UPDATE on it will work. At the moment.

> This wouldn't work if plpythonu ever installs a VALIDATOR, but you
> might be able to use it until such time (barring objections about why
> it's a Bad Idea, that is).

The proposed hack seems far too simplistic to me ... what of CRs that
are deliberately included in string literals?

I don't know Python at all, so I don't know how complicated its lexical
structure is, but ISTM you'd at least need enough smarts to distinguish
literals from unquoted whitespace.

The other small fly in the ointment is that when the server is running
on Windows, I suppose we would have to *put in* rather than remove CRs.
Sim probably doesn't care about that case, but we couldn't accept an
official patch that doesn't handle it.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message peter Willis 2005-03-14 15:56:48 Re: Question about accessing current row data inside trigger
Previous Message Rick Schumeyer 2005-03-14 15:43:25 Re: prelimiary performance comparison pgsql vs mysql