Re: SQL query editor

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....

Responses

Browse pgadmin-support by date

  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