Re: ecpg - GRANT bug

From: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org, Michael Meskes <meskes(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: ecpg - GRANT bug
Date: 2001-10-15 14:32:27
Message-ID: 15306.62331.332853.699939@elsick.csl.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Tom Lane writes:
> Lee Kindness <lkindness(at)csl(dot)co(dot)uk> 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 shouldn't be ecpg's business to throw errors on behalf of
> the backend, especially not "not yet implemented" kinds of errors.
> That just causes ecpg to be more tightly coupled to a particular backend
> version than it needs to be.

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).
COMMIT: AND [NO] CHAIN options? Where do these come from,
it's not ANSI (i'd probably leave this one).

Perhaps an ET_NOTICE should still be output however...

Let me known if you want a patch for these cases too.

Regards, Lee Kindness.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2001-10-15 15:35:57 Re: probably a bug of data-type serial
Previous Message Tom Lane 2001-10-15 14:10:40 Re: ecpg - GRANT bug

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2001-10-15 14:38:22 Re: java
Previous Message Tom Lane 2001-10-15 14:18:31 Re: Pre-forking backend