On Fri, Oct 19, 2001 at 09:37:59AM +0200, Christof Petig wrote:
> I somewhat got the impression that using C++ style comments (//) are related
> to worse the problem. But I must confess I didn't dig deep enough to contribute
> anything substancial. Perhaps the problem is a misunderstanding of ecp
Michael Meskes wrote:
> On Tue, Oct 16, 2001 at 10:27:42AM +0100, Lee Kindness wrote:
> > And the patch below corrects a pet peeve I have with ecpg, all errors
> > and warnings are output with a line number one less than reality...
>
> I wish I knew where this comes from. I've been trying to trac
Michael will apply the required patches.
> Tom Lane writes:
> > Uh, isn't the correct fix
> > ! $$ = cat_str(8, make_str("grant"), $2, make_str("on"), $4, $5,
> > make_str("to"), $7, $8);
> > ISTM your patch loses the opt_with_grant clause. (Of course the
> > backend doesn't currently acce
> > On Tue, Oct 16, 2001 at 10:16:38AM +0100, Lee Kindness wrote:
> > > Patch below, it changes:
> > > ...
> >
> > I just added this to my sources. Will commit in a few minutes.
>
> Michael, I will let you apply the ecpg patches you desire.
I have removed all the ecpg patches from the unapplied
Michael will apply the required patches.
> Bruce Momjian writes:
> > Lee Kindness writes:
> > > In which case a number of other cases should be weeded out of
> > > parser.y and passed onto the backend:
> > > [ snip ]
> > > Let me known if you want a patch for these cases too.
> > Sure, sen
> On Tue, Oct 16, 2001 at 10:16:38AM +0100, Lee Kindness wrote:
> > Patch below, it changes:
> > ...
>
> I just added this to my sources. Will commit in a few minutes.
Michael, I will let you apply the ecpg patches you desire.
--
Bruce Momjian| http://candle.pha.pa.u
[Sorry, for the late replies, but I was on the road since Sunday.]
On Mon, Oct 15, 2001 at 10:10:40AM -0400, Tom Lane wrote:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > The existing code in ecpg/preproc/preproc.y to handle the WITH option
> > simply throws an error and aborts the processing...
On Tue, Oct 16, 2001 at 10:27:42AM +0100, Lee Kindness wrote:
> And the patch below corrects a pet peeve I have with ecpg, all errors
> and warnings are output with a line number one less than reality...
I wish I knew where this comes from. I've been trying to track this bug down
for years now, b
On Tue, Oct 16, 2001 at 10:16:38AM +0100, Lee Kindness wrote:
> Patch below, it changes:
> ...
I just added this to my sources. Will commit in a few minutes.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
-
Bill Studenmund writes:
> I think this patch is wrong. Wouldn't it be better to make the line number
> in yylineno be correct? Also, there are users of the line number in pcg.l
> which you didn't change.
> Looking at it, I don't see why the line number is off. It is initialized
> to 1 at the
Lee Kindness writes:
> COMMIT: AND [NO] CHAIN options? Where do these come from,
> it's not ANSI (i'd probably leave this one).
Sure is.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)--
On Tue, 16 Oct 2001, Lee Kindness wrote:
> And the patch below corrects a pet peeve I have with ecpg, all errors
> and warnings are output with a line number one less than reality...
I think this patch is wrong. Wouldn't it be better to make the line number
in yylineno be correct? Also, there ar
I agree we need to find out why the line number is off rather than
covering up the problem. Patch rejected.
---
> Lee Kindness writes:
> > Patch below, it changes:
> > 1. A number of mmerror(ET_ERROR) to mmerror(ET_NOTI
Lee Kindness <[EMAIL PROTECTED]> writes:
> And the patch below corrects a pet peeve I have with ecpg, all errors
> and warnings are output with a line number one less than reality...
Hmm. yylineno *should* be the right thing. I think you are patching
a symptom rather than fixing the correct cau
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
> Tom Lane writes:
> > Uh, isn't the correct
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
> Lee Kindness writes:
> > Patch below, it ch
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
> Bruce Momjian writes:
> > Lee Kindness writ
Bruce Momjian writes:
> Lee Kindness writes:
> > In which case a number of other cases should be weeded out of
> > parser.y and passed onto the backend:
> > [ snip ]
> > Let me known if you want a patch for these cases too.
> Sure, send them on over.
Patch below, it changes:
1. A number o
Lee Kindness <[EMAIL PROTECTED]> writes:
> The existing code in ecpg/preproc/preproc.y to handle the WITH option
> simply throws an error and aborts the processing... The patch below
> prevents the segfault and also passes on the WITH option to the
> backend, probably a better fix.
I agree. It s
Patch applied. Thanks.
---
> Tom Lane writes:
> > Uh, isn't the correct fix
> > ! $$ = cat_str(8, make_str("grant"), $2, make_str("on"), $4, $5,
> > make_str("to"), $7, $8);
> > ISTM your patch loses the opt_with_gran
> In which case a number of other cases should be weeded out of
> parser.y and passed onto the backend:
>
> CREATE TABLE:GLOBAL TEMPORARY option.
> CREATE FUNCTION: IN/OUT/INOUT options (note there's a bug in parser.y
> there anyway, it would pass on 'oinut' for INOUT).
>
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > The existing code in ecpg/preproc/preproc.y to handle the WITH option
> > simply throws an error and aborts the processing... The patch below
> > prevents the segfault and also passes on the WITH option to the
> > backend, probab
Tom Lane writes:
> Uh, isn't the correct fix
> ! $$ = cat_str(8, make_str("grant"), $2, make_str("on"), $4, $5,
> make_str("to"), $7, $8);
> ISTM your patch loses the opt_with_grant clause. (Of course the
> backend doesn't currently accept that clause anyway, but that's no
> reason for ecpg
23 matches
Mail list logo
