2009/11/14 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Florian G. Pflug f...@phlo.org 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
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 f...@phlo.org:
Hi
I'm currently working on a project where we need to build a global cache
table
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
2009/11/14 Andrew Dunstan and...@dunslane.net:
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
Andrew Dunstan and...@dunslane.net 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Florian G. Pflug f...@phlo.org 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,
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Andrew Dunstan and...@dunslane.net 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Florian G. Pflug f...@phlo.org 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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
Andrew Dunstan and...@dunslane.net 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
Florian G. Pflug f...@phlo.org 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
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us 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
2009/11/14 Merlin Moncure mmonc...@gmail.com:
On Sat, Nov 14, 2009 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us 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
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
Florian G. Pflug f...@phlo.org 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
Tom Lane wrote:
Florian G. Pflug f...@phlo.org 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,
Florian G. Pflug f...@phlo.org 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
24 matches
Mail list logo
