It appears to me that there is a bug in gram.y. From looking at the code
(while working on ecpg) it seems that it doesn't accept a createdb with th
eoption: with location = ... but without the option with encoding = ...

Michael
-- 
Dr. Michael Meskes		meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Mon, 3 Aug 1998 17:15:16 +0200
"Dr. Michael Meskes" <meskes@online-club.de>
Bug in gram.y?
> It appears to me that there is a bug in gram.y. From looking at the code
> (while working on ecpg) it seems that it doesn't accept a createdb with th
> eoption: with location = ... but without the option with encoding = ...

Looks fine to me:

opt_database1:  LOCATION '=' location           { $$ = $3; }
        | /*EMPTY*/                             { $$ = NULL; }
        ;
                    
opt_database2:  ENCODING '=' encoding           { $$ = $3; }
        | /*EMPTY*/                             { $$ = NULL; }
        ;
                    


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Mon, 3 Aug 1998 14:19:44 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Bug in gram.y?
> > it seems that it doesn't accept a createdb with the
> > option location = ... but without the option encoding = ...

I think the code is sub-optimal for a couple of reasons:

1) LOCATION must be the first argument, ENCODING must be the second. The
number and order of any options should be flexible.

2) the options should have a comma delimiter between them. Currently
they do not. To introduce the comma delimiter will require restructuring
that part of the parsing, but isn't a big deal.

I'm pretty sure that the options can be specified individually, but it
does not generalize well. The two specific problems above should be
considered fatal for a final version :/

I've worked through problems like this for other SQL92 syntax, and can
probably fix up this one too. Will put it on my list unless someone else
wants it...

                        - Tom

Tue, 04 Aug 1998 02:10:02 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Bug in gram.y?
>> > it seems that it doesn't accept a createdb with the
>> > option location = ... but without the option encoding = ...
>
>I think the code is sub-optimal for a couple of reasons:
>
>1) LOCATION must be the first argument, ENCODING must be the second. The
>number and order of any options should be flexible.
>
>2) the options should have a comma delimiter between them. Currently
>they do not. To introduce the comma delimiter will require restructuring
>that part of the parsing, but isn't a big deal.
>
>I'm pretty sure that the options can be specified individually, but it
>does not generalize well. The two specific problems above should be
>considered fatal for a final version :/
>
>I've worked through problems like this for other SQL92 syntax, and can
>probably fix up this one too. Will put it on my list unless someone else
>wants it...

I'm responsible for that problem. But seems you have a better
solution. Please take it.
--
Tatsuo Ishii
t-ishii@sra.co.jp




Tue, 04 Aug 1998 11:31:40 +0900
t-ishii@sra.co.jp
Re: [HACKERS] Bug in gram.y? 
On Mon, Aug 03, 1998 at 02:19:44PM -0400, Bruce Momjian wrote:
> Looks fine to me:
> 
> opt_database1:  LOCATION '=' location           { $$ = $3; }
>         | /*EMPTY*/                             { $$ = NULL; }
>         ;
>                     
> opt_database2:  ENCODING '=' encoding           { $$ = $3; }
>         | /*EMPTY*/                             { $$ = NULL; }
>         ;

Yes, but check the code under CreatedbStmt:

					n->dbpath = $5;
#ifdef MULTIBYTE
                                        if ($6 != NULL) {
                                                n->encoding = pg_char_to_encoding($6);
                                                if (n->encoding < 0) {
                                                        elog(ERROR, "invalid encoding name %s", $6);
                                                }
                                        } else {
                                                n->encoding = GetTemplateEncoding();
                                        }
#else
                                        elog(ERROR, "WITH ENCODING is not supported");
#endif
                                        $$ = (Node *)n;


If you have undefined MULTIBYTE you will get the WITH ENCODING error message
despite the command being legal even without this option.

Michael
-- 
Dr. Michael Meskes		meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Tue, 4 Aug 1998 07:52:31 +0200
"Dr. Michael Meskes" <meskes@online-club.de>
Re: [HACKERS] Bug in gram.y?
> On Mon, Aug 03, 1998 at 02:19:44PM -0400, Bruce Momjian wrote:
> > Looks fine to me:
> > 
> > opt_database1:  LOCATION '=' location           { $$ = $3; }
> >         | /*EMPTY*/                             { $$ = NULL; }
> >         ;
> >                     
> > opt_database2:  ENCODING '=' encoding           { $$ = $3; }
> >         | /*EMPTY*/                             { $$ = NULL; }
> >         ;
> 
> Yes, but check the code under CreatedbStmt:
> 
> 					n->dbpath = $5;
> #ifdef MULTIBYTE
>                                         if ($6 != NULL) {
>                                                 n->encoding = pg_char_to_encoding($6);
>                                                 if (n->encoding < 0) {
>                                                         elog(ERROR, "invalid encoding name %s", $6);
>                                                 }
>                                         } else {
>                                                 n->encoding = GetTemplateEncoding();
>                                         }
> #else
>                                         elog(ERROR, "WITH ENCODING is not supported");
> #endif
>                                         $$ = (Node *)n;
> 
> 
> If you have undefined MULTIBYTE you will get the WITH ENCODING error message
> despite the command being legal even without this option.

Good point.  I have changed it to:

>                                         } else {
>                                                 n->encoding = GetTemplateEncoding();
>                                         }
> #else
>                                         if ($6 != NULL)
                                          ^^^^^^^^^^^^^^^
>                                                 elog(ERROR, "WITH ENCODING is not supported");
> #endif
>                                         $$ = (Node *)n;

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Tue, 4 Aug 1998 13:37:30 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Bug in gram.y?