2009/11/14 Merlin Moncure :
> On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane wrote:
>> This might look neat but I don't think it's actually useful for any
>> production application. We'd need to find some way of expressing it
>> that allows caching of the expression plans. But really I think the
>> e
2009/11/14 Merlin Moncure :
> On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane wrote:
>> This might look neat but I don't think it's actually useful for any
>> production application. We'd need to find some way of expressing it
>> that allows caching of the expression plans. But really I think the
>> e
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane wrote:
> This might look neat but I don't think it's actually useful for any
> production application. We'd need to find some way of expressing it
> that allows caching of the expression plans. But really I think the
> entire approach is pretty much back
"Florian G. Pflug" writes:
> Still, doing that SELECT seems rather silly since NEW and OLD already
> contain the required information. So I still believe that having
> something like record_name() and record_types() would be useful. And at
> least these functions have less of an issue with the typ
Andrew Dunstan writes:
> Tom Lane wrote:
>>> Perhaps it would help if we looked at some specific use-cases that
>>> people need, rather than debating abstractly. What do you need your
>>> generic trigger to *do*?
> One case I have is a custom audit package that ignores certain fields
> when log
Tom Lane wrote:
"Florian G. Pflug" writes:
Tom Lane wrote:
Perhaps it would help if we looked at some specific use-cases
that people need, rather than debating abstractly. What do you
need your generic trigger to *do*?
I need to build a global index table of all values of a certain
type to
"Florian G. Pflug" writes:
> Tom Lane wrote:
>> Perhaps it would help if we looked at some specific use-cases that
>> people need, rather than debating abstractly. What do you need your
>> generic trigger to *do*?
> I need to build a global index table of all values of a certain type
> togethe
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Perhaps it would help if we looked at some specific use-cases that
people need, rather than debating abstractly. What do you need your
generic trigger to *do*?
The two things I have wanted most badly in the past are
Tom Lane wrote:
"Florian G. Pflug" writes:
While I agree that handling arbitrary datatypes at runtime would be
nice, I really don't see how that could ever be done from within a
plpgsql procedure, unless plpgsql somehow morphs into a
dynamically typed language.
Which is not likely to happen
Andrew Dunstan writes:
> Tom Lane wrote:
>> Perhaps it would help if we looked at some specific use-cases that
>> people need, rather than debating abstractly. What do you need your
>> generic trigger to *do*?
> The two things I have wanted most badly in the past are
> a) to be able to address
Tom Lane wrote:
"Florian G. Pflug" writes:
While I agree that handling arbitrary datatypes at runtime would be
nice, I really don't see how that could ever be done from within a
plpgsql procedure, unless plpgsql somehow morphs into a dynamically
typed language.
Which is not likely
"Florian G. Pflug" writes:
> While I agree that handling arbitrary datatypes at runtime would be
> nice, I really don't see how that could ever be done from within a
> plpgsql procedure, unless plpgsql somehow morphs into a dynamically
> typed language.
Which is not likely to happen, which is
Tom Lane wrote:
Andrew Dunstan writes:
Yes, and I have used it, but it really would be nicer to have some
introspection facilities built in, especially for use in triggers.
Maybe, but the proposal at hand is spectacularly ugly --- in particular
it seems designed around the assumption that a g
Tom Lane wrote:
"Florian G. Pflug" writes:
Ok, I must be missing something. I currently fail to see how my
proposed record_value(record, name, anyelement) returns anyelement
function differs (from the type system's point of view) from
value_from_string(text, anyelement) returns anyelement whi
Andrew Dunstan writes:
> Yes, and I have used it, but it really would be nicer to have some
> introspection facilities built in, especially for use in triggers.
Maybe, but the proposal at hand is spectacularly ugly --- in particular
it seems designed around the assumption that a given trigger wi
2009/11/14 Andrew Dunstan :
>
>
> Pavel Stehule wrote:
>>
>> Hello
>>
>> new hstore has a very nice interface for record field iteration
>>
>>
>
> Yes, and I have used it, but it really would be nicer to have some
> introspection facilities built in, especially for use in triggers.
I am not sure.
Pavel Stehule wrote:
Hello
new hstore has a very nice interface for record field iteration
Yes, and I have used it, but it really would be nicer to have some
introspection facilities built in, especially for use in triggers.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pg
Hello
new hstore has a very nice interface for record field iteration
http://okbob.blogspot.com/2009/10/dynamic-access-to-record-fields-in.html
Regards
Pavel Stehule
2009/11/13 Florian G. Pflug :
> Hi
>
> I'm currently working on a project where we need to build a global cache
> table containin
"Florian G. Pflug" writes:
> Ok, I must be missing something. I currently fail to see how
> my proposed
>record_value(record, name, anyelement) returns anyelement
> function differs (from the type system's point of view) from
>value_from_string(text, anyelement) returns anyelement
> which
Tom Lane wrote:
"Florian G. Pflug" writes:
Tom Lane wrote:
Trying to do this in plpgsql is doomed to failure and heartache,
Well, the proposed functions at least allow for some more
flexibility in working with row types, given that you know in
advance which types you will be dealing with (b
"Florian G. Pflug" writes:
> Tom Lane wrote:
>> Trying to do this in plpgsql is doomed to failure and heartache,
> Well, the proposed functions at least allow for some more flexibility in
> working with row types, given that you know in advance which types you
> will be dealing with (but not nece
Tom Lane wrote:
"Florian G. Pflug" writes:
I'd like to replace this function-generating function by a generic
trigger function that works for all tables. Due to the lack of any
way to inspect the *structure* of a record type, however, I'd have
to use a C language function for that, which induc
"Florian G. Pflug" writes:
> I'd like to replace this function-generating function by a generic
> trigger function that works for all tables. Due to the lack of any way
> to inspect the *structure* of a record type, however, I'd have to use a
> C language function for that, which induces quite som
Hi
I'm currently working on a project where we need to build a global cache
table containing all values of certain types found in any of the other
tables. Currently, a seperate insert, update and delete (plpgsql)
trigger function exists for each table in the database which is
auto-generated by a
24 matches
Mail list logo
