Some years ago I floated an idea for decorating functions with properties. I forget exactly the context in which it occurred to me, but the suggestion met a very frosty reception indeed, and, discretion being the better part of valour, I didn't pursue it.
But the notion of doing something like this has twice come back to me in the last week or so, once in conjunction with something I was discussing about PLV8, and once in conjunction with a proposal I have been discussing to do with making PLPerl more efficient.
The PLPerl issue is easily stated: when it's dealing with records, including records passed to PLPerl as arguments, records returned as results, and records fetched via SPI, the PLPerl glue code turns the records into perl hashrefs, and expects to be handed hashrefs by plperl functions. Now hashrefs are horribly inefficient when handling bulk data, and massively redundant when it comes to sets of database rows, which all have the same field names . Passing data as arrayrefs is much more efficient. But doing this means that the perl code would lose the field names, and would need to know to provide / expect arrayrefs rather than hashrefs. If we made a change like this globally, it would break a mountain of legacy code. So we want to be able to do this on a per function basis.
One idea is to create a separate language to handle data this way. It could share a lot of code with the existing language, possibly even sharing interpreters, but we'd know to provide and expect arrayrefs instead of hashrefs for records. But this solution is really a bit ugly and kludgy.
So I'm currently playing around with the idea of leveraging an existing capability that we added in 8.3, namely the ability to set a configuration parameter as part of a function's definition. One nice part about this is it wouldn't need to change any existing catalogs etc. The only affected code (I hope) would be in the language's glue code. There are probably a few nasty wrinkles. but I'm hopeful it will work.
The idea is we'd do something like:
But the notion of doing something like this has twice come back to me in the last week or so, once in conjunction with something I was discussing about PLV8, and once in conjunction with a proposal I have been discussing to do with making PLPerl more efficient.
The PLPerl issue is easily stated: when it's dealing with records, including records passed to PLPerl as arguments, records returned as results, and records fetched via SPI, the PLPerl glue code turns the records into perl hashrefs, and expects to be handed hashrefs by plperl functions. Now hashrefs are horribly inefficient when handling bulk data, and massively redundant when it comes to sets of database rows, which all have the same field names . Passing data as arrayrefs is much more efficient. But doing this means that the perl code would lose the field names, and would need to know to provide / expect arrayrefs rather than hashrefs. If we made a change like this globally, it would break a mountain of legacy code. So we want to be able to do this on a per function basis.
One idea is to create a separate language to handle data this way. It could share a lot of code with the existing language, possibly even sharing interpreters, but we'd know to provide and expect arrayrefs instead of hashrefs for records. But this solution is really a bit ugly and kludgy.
So I'm currently playing around with the idea of leveraging an existing capability that we added in 8.3, namely the ability to set a configuration parameter as part of a function's definition. One nice part about this is it wouldn't need to change any existing catalogs etc. The only affected code (I hope) would be in the language's glue code. There are probably a few nasty wrinkles. but I'm hopeful it will work.
The idea is we'd do something like:
create function foo()
returns void
set plperl.rows_as_arrayrefs = true
language plperl as
$$ ... $$;