> -----Original Message-----
> From: Tim Finch [mailto:pgsql@timfinch.cix.co.uk]
> Sent: 03 April 2002 09:48
> To: Dave Page
> Cc: pgadmin-support@postgresql.org; G. A. Reina
> Subject: Re: [pgadmin-support] SQL query editor
>
>
> At 07:21 30/03/2002 +0000, Dave Page wrote:
> >No, it doesn't I'm afraid. It's possible that it could be
> modularised
> >and
> >seperated though, and it's a pretty good idea, so if I get a
> chance I'll
> >look into it.
> >
> >Regards, Dave.
>
> Is it worth us thinking sbout this in terms of the graphical
> editor we are
> working on, Dave?
> There is some sense possibly in the designer being both an
> addin and a
> standalone EXE, that in standalone mode produces SQL strings on the
> clipboard perhaps. If Tony is after an ability to 'restrict'
> whatusers can
> do in the pgAdminII, then surely a better approach is to have
> security in
> pgAdminII that states what operators of pgAdminII can do (you
> can create
> Dbs, edit them, create SQL etc. etc.)...?
> Tim.
Not a good idea. Security is the job of the DBMS - anything we can do with
pgAdmin could be overidden by a registry savvy user anyway, or by deleting
files/reinstalling if we used other methods. Admittedly in NT based OS's
you've got a little more control over what the user can/can't do.
I think the best answer would be to put the SQL code, SQL Wizard and Query
Designer in a .dll, which can be called by pgAdmin as required, which could
just pass the connection object and database name to use. For users such as
Tony's, we build a small host program which logs the user on to the
specified datasource (I probably would use DSNs for that like pgAdmin I),
and then calls the dll in the same way. The sysadmin could then install
either the full product or just the query tool on his users boxes.
'Course, the downside is that I just committed code to the datagrid that
ties it into pgSchema for the first time!! (Use Primary Keys for
updating/deleting rows in the data editor where possible.)
Never mind....
Regards, Dave.
