Re: how to start a procedure after postgresql started. - Mailing list pgsql-general

From jun yang
Subject Re: how to start a procedure after postgresql started.
Date
Msg-id BANLkTimuWQgEvZ7hstpxLLpi2de9TeJ6xw@mail.gmail.com
Whole thread Raw
In response to Re: how to start a procedure after postgresql started.  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-general
2011/5/24 Craig Ringer <craig@postnewspapers.com.au>:
> On 24/05/11 12:46, jun yang wrote:
>
>> thanks for the info,i am just not have such deep learn of pg internal,
>> i am on user level,not hacker,so the mail is in pgsql-general,not
>> hacker list.
>
> Then you really, really, REALLY don't want to start a thread within the
> backend, and should avoid spawning processes from backends too. To get
> either approach right will require a much deeper understanding of how Pg
> works.
>
thanks for your warnning again.

>>> Part of the reason the postmaster hasn't been altered to support managing
>>> daemons is because some people (understandably) think that that's the OS's
>>> job, and not something PostgreSQL should duplicate.
>>>
>> well,from user viewpoint,i prefer that pg bundle with such
>> function,like extension in pg,the function default is disable.make it
>> easier for those who need it will be a promotion for pg.
>> many commercial db production include such a schedule function, not
>> only for making money,there is user need in practice.
>
> Yep, I think it'd be nice. Nobody has volunteered to write such a
> feature yet, though, and nobody is stepping up to pay someone else to
> write it. Or at least any efforts so far haven't reached
> production-quality committable code.
>
even a basic pim program has buildin schedule function,so it should
not be so hard for a big software like pg.
the important of buildin schedule function is that the whole schedule
is in pg ,you can dump and restore database,that's all,no need to
examine all external things run ok.
> The downside of working with an open source database is that there's no
> incentive to write marketing-checkbox features. Someone has to actually
> want to put in the time and effort to implement it, usually because they
> want to use it.
>
haha,it seems i demand too much and can't put in the time and effort.
i am terribly sorry about that.

>> yes,it is so complicated for a common user to do such things.
>
> ... which is why the VAST majority of people achieve what they need
> using a separate daemon or just integrate this sort of functionality
> into their middleware. Neither option is difficult to do.
>
> What you want to do - integrate your app directly and completely into
> the database - is not something that a common user typically wants to do
> in the first place.
>
yes,it is like hacking pg.

> It's more common for people who want to hide the database behind a
> messaging system to instead write a program that accepts messages and
> embed a database like Berkeley DB, SQLite or Firebird directly into
> their program, rather than the other way around. PostgreSQL cannot be
> embedded that way, it's not designed for that kind of use.
>
i found pg_amqp,some thing like what i want to do,though by write a pg
module in c,if pg support write pg module by it's procedure
language,there would be more people can hack pg.
> --
> Craig Ringer
>

pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Returning Rows in Procedure
Next
From: Craig Ringer
Date:
Subject: Re: Postgres questions