On 17/02/10 18:30, David E. Wheeler wrote:
On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
Umm, perhaps F-funcname(@args), or PG-funcname(@args), or ... ?
Anyone got any better suggestions?
PG is good. Or maybe DB?
It's a module whose only use is embedded in a DB called PG - not sure
those
On Wed, Feb 17, 2010 at 10:30:03AM -0800, David E. Wheeler wrote:
On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
Yes, but if it's a variadic function, I suspect that it won't often be
called with the same number of args. So you'd potentially end up
caching a lot of extra stuff that would
Tim Bunce tim.bu...@pobox.com writes:
I like F-funcname or FN-funcname myself.
Thanks. I quite like FN.
Anybody else want to express an opinion on the color if this bikeshed
before I repaint it?
I wouldn't have, but since you ask... What about reusing the internal
name, you seem to be
On Feb 18, 2010, at 1:35 AM, Tim Bunce wrote:
http://github.com/timbunce/posgtresql-plperl-call
Thanks, forked.
Thanks. I quite like FN.
Anybody else want to express an opinion on the color if this bikeshed
before I repaint it?
I like PG because it lets you know that you're calling a
On Tue, Feb 16, 2010 at 02:13:30PM -0800, David E. Wheeler wrote:
On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote:
For varadic functions, separate plans are created and cached for each
distinct
number of arguments the function is called with.
Why?
It keeps the code simple and
On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
Yes, but if it's a variadic function, I suspect that it won't often be
called with the same number of args. So you'd potentially end up
caching a lot of extra stuff that would never be used again.
Potentially. Patches welcome!
GitHub. ;-P
On Mon, Feb 15, 2010 at 02:58:47PM -0800, David E. Wheeler wrote:
On Feb 15, 2010, at 2:42 PM, Tim Bunce wrote:
I've not really looked the the DBD::Pg code much so this seemed like a
good excuse... It looks like the default is to call PQprepare() with
paramTypes Oid values of 0.
Yes,
On Feb 16, 2010, at 4:08 AM, Tim Bunce wrote:
Yes, IIRC, 0 == unknown as far as the server is concerned. It just
tells the server to resolve it when it can.
An extra source of puzzlement is that the oid of the 'unknown' type is
705 not 0, and the unknown type isn't discussed in the docs (as
On Tue, Feb 16, 2010 at 09:11:24AM -0800, David E. Wheeler wrote:
An extra source of puzzlement is that the oid of the 'unknown' type is
705 not 0, and the unknown type isn't discussed in the docs (as far as I
could see).
Yes, I noticed that, too. Greg, do you know the answer to that?
My
On 16/02/10 17:11, David E. Wheeler wrote:
On Feb 16, 2010, at 4:08 AM, Tim Bunce wrote:
Wouldn't work unless you'd installed an AUTOLOAD function into each
schema:: package that you wanted to use. (schema-SP::function_name()
could be made to work but that's just too bizzare :)
Maybe
On Feb 16, 2010, at 9:43 AM, Richard Huxton wrote:
Perhaps it would be better to be explicit about what's going on?
SEARCHPATH-function()
SCHEMA('public')-function2()
Or did SP mean Stored Procedure?
Yes.
On a (kind of) related note, it might be worthwhile to mention search_path in
On 16/02/10 17:51, David E. Wheeler wrote:
On Feb 16, 2010, at 9:43 AM, Richard Huxton wrote:
Perhaps it would be better to be explicit about what's going on?
SEARCHPATH-function()
SCHEMA('public')-function2()
Or did SP mean Stored Procedure?
Yes.
Hmm - might be worth avoiding that in
Richard Huxton wrote:
On 16/02/10 17:51, David E. Wheeler wrote:
On Feb 16, 2010, at 9:43 AM, Richard Huxton wrote:
Perhaps it would be better to be explicit about what's going on?
SEARCHPATH-function()
SCHEMA('public')-function2()
Or did SP mean Stored Procedure?
Yes.
Hmm -
On Tue, Feb 16, 2010 at 09:11:24AM -0800, David E. Wheeler wrote:
On Feb 16, 2010, at 4:08 AM, Tim Bunce wrote:
From the docs:
Immediately after the function name, in parenthesis, a comma separated list
of
type names can be given. For example:
'pi()'
On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote:
I assume that type names can be omitted her, too, yes?
No, it seems not. You have to either repeat the type name the right number
of times, or use '...', which simply duplicates the type name for you
behind the scenes. I'll clarify that in the
On Feb 16, 2010, at 3:01 PM, Tom Lane wrote:
I think the reason the client-side docs recommend using zero is to avoid
having clients know about the unknown type explicitly (in particular, to
discourage people from hardwiring 705 into their code). AFAIR there's
not a lot of difference in
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Feb 16, 2010 at 09:11:24AM -0800, David E. Wheeler wrote:
An extra source of puzzlement is that the oid of the 'unknown' type is
705 not 0, and the unknown type isn't discussed in the docs (as far as I
could see).
Yes, I noticed that,
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
On 12/02/10 23:10, Tim Bunce wrote:
There was some discussion a few weeks ago about inter-stored-procedure
calling from PL/Perl.
I'd greatly appreciate any feedback.
Looks great.
Thanks!
PostgreSQL::PLPerl::Call - Simple
On 15/02/10 10:32, Tim Bunce wrote:
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
Is there any value in having a two-stage interface?
$seq_fn = get_call('nextval(regclass)');
$foo1 = $seq_fn-($seq1);
$foo2 = $seq_fn-($seq2);
I don't think
On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
I've appended the POD documentation and attached the (rough but working)
test script.
I plan to release the module to CPAN in the next week or so.
I'd greatly appreciate
On Mon, Feb 15, 2010 at 10:42:15AM +, Richard Huxton wrote:
On 15/02/10 10:32, Tim Bunce wrote:
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
Is there any value in having a two-stage interface?
$seq_fn = get_call('nextval(regclass)');
$foo1 =
On Mon, Feb 15, 2010 at 10:51:14AM +, Tim Bunce wrote:
On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
I've appended the POD documentation and attached the (rough but working)
test script.
I plan to release the
On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
The signature doesn't just qualify the selection of the function,
it also ensures appropriate interpretation of the arguments.
I could allow call('foo', @args), which could be written call(foo = @args),
but what should that mean in terms of the
On Mon, Feb 15, 2010 at 11:52:01AM -0800, David E. Wheeler wrote:
On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
The signature doesn't just qualify the selection of the function,
it also ensures appropriate interpretation of the arguments.
I could allow call('foo', @args), which could
On Feb 15, 2010, at 2:42 PM, Tim Bunce wrote:
I've not really looked the the DBD::Pg code much so this seemed like a
good excuse... It looks like the default is to call PQprepare() with
paramTypes Oid values of 0.
Yes, IIRC, 0 == unknown as far as the server is concerned. It just tells the
On 12/02/10 23:10, Tim Bunce wrote:
There was some discussion a few weeks ago about inter-stored-procedure
calling from PL/Perl.
I'd greatly appreciate any feedback.
Looks great.
PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from
PostgreSQL PL/Perl
I don't think
On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
I've appended the POD documentation and attached the (rough but working)
test script.
I plan to release the module to CPAN in the next week or so.
I'd greatly appreciate any feedback.
I like the idea overall, and anything that can simplify
There was some discussion a few weeks ago about inter-stored-procedure
calling from PL/Perl.
I thought I'd post the documentation (and tests) for a module I'm
working on to simplify calling SQL functions from PL/Perl.
Here are some real-world examples (not the best code, but genuine
use-cases):
28 matches
Mail list logo
