2011/5/23 Darren Duncan <darren@darrenduncan.net>:
> John R Pierce wrote:
>>
>> On 05/21/11 10:41 PM, Darren Duncan wrote:
>>>
>>> Well, if you can run a stored procedure automatically when Postgres
>>> starts, that looks like a necessary step to being able to implement an
>>> entire application inside Postgres.
>>>
>>> Starting Postgres is running the application. The analogy is that
>>> Postgres is the VM/language interpreter and the stored procedure is the
>>> script to run.
>>>
>>> Now if said stored procedure has access to features that collectively let
>>> it be computationally complete, including arbitrary user I/O, then you're
>>> done.
>>
>> adding a
>>
>> psql -d dbname -c "select myfunc()" &
>>
>> to your postgres service start script would satisfy this....
>
> Good that this at least is possible, and ostensibly it is good enough.
>
> I was actually thinking of something more on the line of a trigger, such
> that the system allows triggers to respond to a wide variety of stimulus,
> such as the stimulus of the DBMS starting up, rather than just the stimulus
> of data-manipulating a table. For the purpose I mention, ideally the user
> wouldn't have to know the name of the main program routine, but would just
> know, its the database or cluster. You could package your database cluster
> and say that *is* the application.
wow,you go far ahead of me,it's interesting. since pg has so many
procedure language,pl/perl,pl/python etc.
>
>> ...but your entire application would be running in a single transaction.
>> I don't think thats a good thing.
>
> Absolutely. But if the kind of stored procedures were supported that can do
> anything a database client can do, including transaction control statements,
> then the main program routine would typically be one of those.
>
> -- Darren Duncan
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
