2011/8/4 Florian Pflug <fgp(at)phlo(dot)org>:
> On Aug4, 2011, at 00:48 , Tom Lane wrote:
>> James Robinson <jlrobins(at)socialserve(dot)com> writes:
>>> Python's getattr() allows for dynamic lookup of attributes on an
>>> object, as in:
>>> inst = MyClass(x=12, y=24)
>>> v = getattr(inst, 'x')
>>> assert v == 12
>>> Oftentimes in writing data validating trigger functions, it'd be real
>>> handy to be able to do a similar thing in plpgsql
>>> Is there something in the internals which inherently prevent this?
>> plpgsql is strongly typed (much more so than python, anyway).
> You've brought forth that argument against dynamic attribute lookup
> in the past, but I remain unconvinced. The fact that plpgsql is strongly
> (or, more precisely, statically) types doesn't really get in the way as
> long as you require the dynamic attribute accessor's return type to be
> determined at compile time (make that "prepare time" in the case of
> The fact that I was able to implement dynamic accessor functions without
> any change to postgres or plpgsql proves that IMHO. The only bit that slightly
> kludgy about this in my opinion is the return-type determining "defvalue"
> argument of fieldvalue(). But again, this has little to do with static vs.
> dynamic typing but rather with the limitations of our support for polymorphic
> @OP: Here's my implementation of the feature you desire as a set of C-language
> functions: https://github.com/fgp/pg_record_inspect. Other people did code up
> similar things in the past, but I currently cannot find any links to their work.
> But it little bit digging in the mailing list archives should turn them up.
it is pltoolbox http://www.pgsql.cz/index.php/PL_toolbox_%28en%29
> best regards,
> Florian Pflug
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
In response to
pgsql-hackers by date
|Next:||From: Boszormenyi Zoltan||Date: 2011-08-04 10:08:21|
|Subject: TRUE/FALSE vs true/false|
|Previous:||From: Yeb Havinga||Date: 2011-08-04 09:12:24|
|Subject: Re: Transient plans versus the SPI API|