From: | "Tim Finch, FosterFinch Ltd" <tim(at)fosterfinch(dot)co(dot)uk> |
---|---|
To: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | "'Tim Finch'" <pgsql(at)timfinch(dot)cix(dot)co(dot)uk>, pgadmin-support(at)postgresql(dot)org, "G(dot) A(dot) Reina" <reina(at)nsi(dot)edu> |
Subject: | Re: SQL query editor |
Date: | 2002-04-03 20:29:21 |
Message-ID: | 5.1.0.14.0.20020403212808.027d5b08@mail.cix.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
This makes sense. I guess for now, however, we just continue the
development of the Graphical Editor in the standard way and worry about
dll-ing it later on.
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....
From | Date | Subject | |
---|---|---|---|
Next Message | Samuele Brignoli | 2002-04-04 10:04:08 | Migrating a very large db |
Previous Message | Dave Page | 2002-04-03 16:14:15 | Re: Question about functions |