Re: hint infrastructure setup (v3)

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: hint infrastructure setup (v3)
Date: 2004-04-06 08:59:12
Message-ID: Pine.LNX.4.58.0404061022440.8826@sablons.cri.ensmp.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


> >>(b) write a new "recursive descendant" parser, and drop "gram.y"
>
> er, that's "recursive descent" :-)

Sorry for my French version.

> Well, unless you are a serious masochist,

I'm not a masochist;-) I'm arguing about where hint should/could be put.

> In fact, considering this thread I'm not sure any of the suggested steps
> will achieve Fabien's goal. ISTM that a smarter "training wheels"
> frontend, perhaps with some modest backend improvements, is likely to
> have better results. ("Oh, you found an error near there - now what do I
> suggest belongs there?")

I cannot see what you're suggesting "practically" as a frontend.

I don't think having another parser next to the first one for better error
messages is a serious option? I would not like to put another parser that
need to be kept synchronized with the first one. So either it is
integrated or linked with the current parser, or it is not there?

Out of the parser, the only information is the offending token (embedded
in the error string) and the character number in the string, that is quite
small a clue to give a hint.

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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2004-04-06 12:59:14 Re: [HACKERS] logging statement levels
Previous Message Fabien COELHO 2004-04-06 08:18:11 Re: hint infrastructure setup (v3)