Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl - Mailing list pgsql-hackers

From Richard Huxton
Subject Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
Date
Msg-id 4B7AD935.3080909@archonet.com
Whole thread Raw
In response to Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
List 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
(asin 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
schemain 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


pgsql-hackers by date:

Previous
From: Rayson Ho
Date:
Subject: Re: OpenVMS?
Next
From: "David E. Wheeler"
Date:
Subject: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl