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

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl
Дата
Msg-id 4B7AD935.3080909@archonet.com
обсуждение исходный текст
Ответ на Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl  ("David E. Wheeler" <david@kineticode.com>)
Ответы Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl  ("David E. Wheeler" <david@kineticode.com>)
Список 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 по дате отправления:

Предыдущее
От: Rayson Ho
Дата:
Сообщение: Re: OpenVMS?
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl