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
Tim Bunce 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 emulating th
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 th
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
thos
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. ;-
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 t
Martijn van Oosterhout 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, too
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
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
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()'
> > 'gen
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 Proced
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 th
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_
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 SP->sc
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 th
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 do
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.
>
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 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), whic
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
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
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 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 great
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 there
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
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 simpli
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
