From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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-15 16:14:03 |
Message-ID: | b42b73151003150914j4156915q7c24833af49fda1e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 15, 2010 at 11:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If we make the implementation be such that "(rec->field)::foo" forces
a runtime cast to foo (rather than throwing an error if it's not type
foo already)
yeah...explicit cast should always do 'best effort'
> The cost of looking up the ever-changing cast function could still be
> unpleasant, although I think we could hide it in the executor expression
> node instead of forcing a whole new parse/plan cycle each time.
right. if you do that, it's still going to be faster than the
dyna-sql/information schema/perl hacks people are doing right now
(assuming they didn't give up and code it in the app). This is rtti
for plpgsql, and functions that use it are going have to be understood
as being slower and to be avoided if possible, like exception
handlers. IMNSHO, this is a small price to pay.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-03-15 16:19:13 | Re: Dyamic updates of NEW with pl/pgsql |
Previous Message | Tom Lane | 2010-03-15 16:06:19 | Re: Ragged latency log data in multi-threaded pgbench |