Re: Dyamic updates of NEW with pl/pgsql

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, David Fetter <david(at)fetter(dot)org>, depesz(at)depesz(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dyamic updates of NEW with pl/pgsql
Date: 2010-03-13 16:58:40
Message-ID: 162867791003130858w67f2c244ob0f1c27e9b3418f8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/3/13 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> I think we need some operator on records+strings for this functionality.
>
> I don't see how you're going to do that without utterly compromising the
> type system.
>
> It's not so horrid to do this type of thing in plperl, pltcl etc because
> you've already bought into an "everything is text" worldview when you
> use those languages.  But plpgsql is strongly typed just like SQL is,
> and I don't think we should undo that.
>

strong typing isn't problem for field updating - and we can do
necessary conversion to target type - for simple expression (without
cached plan).

I like some
var = record[expression];
record[expression] = var;

I don't thing so current static naturel of plpgsql is impossible
problem. It needs just more inteligent assign statement.

Pavel

> (This will also be my main objection to letting hstore into core.
> It has not solved the problem of handling real datatypes.)
>
>                        regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-03-13 16:58:55 Re: Getting to beta1
Previous Message Bruce Momjian 2010-03-13 16:57:33 Re: pq_setkeepalives* functions