Re: Greenplum patch as a diff file - Mailing list pgadmin-hackers

On Tue, Mar 10, 2009 at 7:56 PM, Chuck McDevitt <cmcdevitt@greenplum.com> wrote:

> Yes, it is very much not feature complete.  We had our schedule set to have a first beta-ready version in about a
monthfrom now, not realizing the pgAdmin beta schedule.  So this is somewhat of a rush job. 

I noticed :-). I have the same problem in EDB, though our first beta
was a couple of weeks back.

FYI, during the last cycle, the EDB version of pgAdmin was a little
different from the community version, picking up a couple of features
from the beginning of this development cycle. We maintained it as a
private code branch, but did so in the project's main repository. I
wouldn't necessarily recommend doing that if you can help it, however,
*very* early in the next cycle we will be moving our development from
Subversion to GIT, which will allow us much more flexibility in
working with different branches for EDB & Greenplum etc. which can be
maintained in their own release cycles and continually merged into the
community branch.

>> In the interests of preventing the same problems occuring again,
>> here's what I changed:
>>
>> - Changes to hbaConfigFileFactory::StartDialog and
>> mainConfigFileFactory::StartDialog were removed. The changes made
>> changed the behaviour of them into hbaConfigFactory::StartDialog and
>> mainConfigFactory::StartDialog. The former are intended to open config
>> files from the local filesystem, the latter using pg_file_read() via a
>> connection to a server.
>
> Ok, how do I get the menu to use the latter versions when someone asked to open a config file?
>
> In the Greenplum DB case, there are no config files on the machine running pgAdmin.  The config files are all on the
server,which the user doesn't have access to except through libpq. 

The options on the file menu always open files on the local server. To
open server config files, use the options under Tools -> Server
Configuration.

>>
>> - I added a gpPartition::Refresh function so the treeview could
>> refresh properly in the even of a change to a partition object.
>>
>
> Thanks... I hadn't put that in yet, since right now you can't change them, but had planned to do this before enabling
changingthem. 

The problem is that you can change them, albeit as if they were
tables. Although you copied dlgTable and disabled the
add/change/remove columns buttons, you could still right-click columns
in the treeview and modify them directly, or add news ones. Similarly,
you can also change constraints and indexes etc.

I *think*, that everything is now enabled (or disabled) consistently,
and will work as expected, with the treeview refreshing as it should.
Whether or not it makes sense to add a column to one partition is a
whole other debate of course - but pgAdmin doesn't try to do anything
that that you couldn't do through psql, so I'm happy nothing is
technically broken.

>> - Added code to gpResQueue::ShowTreeDetail to display the thresholds
>> and auto commit setting in the properties list for resource queues.
>>
>> - Fixed the graphical explain to allow it to render a plan with nodes
>> with an average cost of zero. This doesn't happen in
>> PostgreSQL/EnterpriseDB (at least without some pretty funky
>> non-standard tuning parameters), but does on Greenplum with a brand
>> new empty table which caused an arrow to be rendered such that it
>> obscured the entire plan.
>
> Wow... I never thought to test this case!

:-). I was testing initially with empty tables lifted straight from
the docs and ran into this one immediately.

> Yes, dlgPartition was just a placeholder for the code to allow creating/modifying partitions.
> I was thinking it was better to get something that compiles and doesn't fail when run into those modules before the
beta,because I was worried you wouldn't accept adding new files after the beta starts. 

I won't, without a very compelling reason (though we can talk about a
private code branch, as long as all code goes back into trunk
eventually).

We also don't keep placeholder code in release versions unless there
is useful additional functionality there - we prefer to keep the
release code as clean as possible.

> As soon as I have time, I plan to implement working dlgPartition code to allow adding/changing partitions.

Sound good.

> Yes, I understand.  Like I said, I'm sorry for the extra work, and we will try to not have that happen in the future.

Thanks - appreciate it. I'm keen for us to continue to work together;
it's worked well for EDB, improving the tools for our customers, and
the community have benefited from additional developer and QA time in
return. I hope we can work with Greenplum in a similar fashion.


--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com