Roberts, Jon wrote:
>> Roberts, Jon wrote:
>>> There are three problems with having a custom connection string for each
>>> step. 1) If I need to update the connection like change the password, I
>>> have to do it for each step. 2) Developers will see the password in
>> clear
>>> text.
>> I consi
> Roberts, Jon wrote:
> > There are three problems with having a custom connection string for each
> > step. 1) If I need to update the connection like change the password, I
> > have to do it for each step. 2) Developers will see the password in
> clear
> > text.
>
> I consider those irrelevant
Roberts, Jon wrote:
> There are three problems with having a custom connection string for each
> step. 1) If I need to update the connection like change the password, I
> have to do it for each step. 2) Developers will see the password in clear
> text.
I consider those irrelevant because plast
>
> > However, to make pgAgent and pgAdmin work better with my solution, it
> would
> > be nice to have an enhancement. The enhancement could also benefit
> others
> > wanting to separate the database server where jobs are maintained from
> the
> > target server(s) where sql should be executed.
>
Roberts, Jon wrote:
> I found more problems when trying to use GP. For instance, this update
> statement will not work in GP.
>
> UPDATE pgagent.pga_jobsteplog SET jslstatus='d'
> WHERE jslid IN SELECT jslid
> FROM pga_tmp_zombies z, pgagent.pga_job j, pgagent.pga_joblog l,
> pgagent.pga_jobste
; Cc: pgadmin-hackers
> Subject: Re: [pgadmin-hackers] Using pgAdmin and pgAgent with Greenplum
>
> Roberts, Jon wrote:
> > I've looked at this code all day long and tried many hacks to make it
> work
> > with GP but there isn't a way.
> >
> > The eas
Roberts, Jon wrote:
> I've looked at this code all day long and tried many hacks to make it work
> with GP but there isn't a way.
>
> The easiest way I can think of to handle this with the least amount of
> change to the architecture is to add another column to pg_job. Maybe a
> Boolean called
Roberts, Jon wrote:
> I am using pgAdmin with Greenplum and generally, it works very well. It
> doesn't show the distribution of tables but that isn't a big deal.
>
> I now need a scheduling solution and pgAgent is the natural choice. I first
> reviewed this and saw that the query that is launch
I am using pgAdmin with Greenplum and generally, it works very well. It
doesn't show the distribution of tables but that isn't a big deal.
I now need a scheduling solution and pgAgent is the natural choice. I first
reviewed this and saw that the query that is launched by pgAdmin contains a
corre
