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
|
Список | 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 по дате отправления: