Re: Proposed GUC Variable

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: Proposed GUC Variable
Дата
Msg-id 1030637398.3216.94.camel@camel
обсуждение исходный текст
Ответ на Re: Proposed GUC Variable  (Gavin Sherry <swm@linuxworld.com.au>)
Ответы Re: Proposed GUC Variable  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposed GUC Variable  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Список pgsql-hackers
One of my users is generating a notice message --> NOTICE:  Adding
missing FROM-clause entry for table "msg202"  It might be helpful to
dump out the query on notice messages like this, and it looks like a
simple change as far as elog.c and guc.c are concerned, but would this
be overkill?

Robert Treat

On Wed, 2002-08-28 at 02:26, Gavin Sherry wrote:
> On Wed, 28 Aug 2002, Gavin Sherry wrote:
>
> > On Tue, 27 Aug 2002, Tom Lane wrote:
> >
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > But we should have some default to print some of the query,
> > >
> > > Why?  So far you've been told by two different people (make that three
> > > now) that such a behavior is useless, and no one's weighed in in its
> > > favor ...
> >
> > I completely agree. Nothing wrong with adding another guc variable and
> > since it is a debug variable people expect lots of verbosity.
>
> Attached is the patch. debug_print_error_query is set to false by default.
>
> For want of a better phrase, I've prepended 'original query: ' to the
> error message to highlight why it is in the log.
>
> Gavin
>
> ----
>

>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Следующее
От: "Thomas F. O'Connell"
Дата:
Сообщение: the optimizer and exists