Re: Further thoughts about warning for costly FK checks

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Richard Huxton <dev(at)archonet(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Further thoughts about warning for costly FK checks
Date: 2004-03-18 10:18:47
Message-ID: Pine.LNX.4.58.0403181105200.24164@sablons.cri.ensmp.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Dear Tom,

On Wed, 17 Mar 2004, Tom Lane wrote:
> If you want a GUI, it could be a GUI,

I do not want a GUI, I'm not a GUI guy;-) I was just wondering how GUI
could be adapted to deal with the tool if it is outside.

> though I'd be worried about the portability price paid to have one. Or
> are you concerned about whether a GUI could invoke it? I don't see why
> not --- the GUIs don't reimplement pg_dump, do they?

Yes, but pg_dump is more like a blackbox, the interface does not need
to look at the generated output and interpret it, or in a very simple
way to check whether it failed.

> > Or separate only mean that it is a "separate" function of the backend that
> > can be triggered by calling existing functions such as "EXPLAIN" or
> > "ANALYZE" or new ones such as "CHECK" or "ADVICE" or whatever.
>
> That still leaves us in the situation where only people who are capable
> of doing backend programming can help. I hope that a standalone program
> would be more understandable and could attract developers who wouldn't
> touch the backend.

Mmm. The tool would need support functions that should already exist
in the backend, so they will be re-developed or somehow replicated.

Moreover I'm among the ones asking for advices, and I'm not that afraid of
the backend, as maybe I should be;-)

Also, I would like to get the advices simply from psql, thus an added
command (ADVISE) or even ANALYZE would be just fine.

> Also, you'd still have to invent an interface for it --- and the
> interface would be constrained by the limits of the FE/BE protocol.
> It would have to look like a SQL command that returns a query result,
> or possibly NOTICE messages, both of which are pretty confining.

I think that such tool would generate "WARNING, NOTICE", HINT, CONTEXT
just as the be does at the time, so I don't think that it is that
confining. Also, some new fields could be added to improve reports,
if they are really necessary, but I'm not even that sure that any is
needed.

Well, anyway if there is some place to put advices, that would be a good
think, even if I'm not convinced about the design;-)

Have a nice day,

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Francisco Reyes 2004-03-18 10:26:25 Inherited tables
Previous Message Fabien COELHO 2004-03-18 09:51:36 syntax error position "CREATE FUNCTION" bug fix