From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Greg Sabino Mullane <greg(at)endpoint(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl |
Date: | 2010-02-16 17:43:17 |
Message-ID: | 4B7AD935.3080909@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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->schema('public')->function_name()? I kind of like the idea of objects created for specific schemas, though (as in your example). Maybe that, too, is something that could be specified in the `use`statement. Or maybe `SP::schema->function`? That's kind of nice, keeps things encapsulated under SP. You could then do the identifier quoting, too. The downside is that, once loaded, the schema package names would be locked down. If I created a new schema in the connection, SP wouldn't know about it.
Perhaps it would be better to be explicit about what's going on?
SEARCHPATH->function()
SCHEMA('public')->function2()
Or did "SP" mean "Stored Procedure"?
On a (kind of) related note, it might be worthwhile to mention
search_path in the docs and point out it has the same pros/cons as unix
file paths.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Brantner | 2010-02-16 17:47:25 | Re: XQuery support |
Previous Message | Rayson Ho | 2010-02-16 17:39:29 | Re: OpenVMS? |