Re: ecpg weird behavior

From: "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au>
To: "Michael Meskes" <meskes(at)postgresql(dot)org>
Cc: <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: ecpg weird behavior
Date: 2002-03-20 03:15:06
Message-ID: 011501c1cfbd$6f899260$660d090a@software.ingenico.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

I don't see this e-mail in the thread so I resend it with the attached file
in the text.
Beware that this is not a pacth to apply. Just that I have reach the limit
of my knowledge on bison and can't find out what's wrong (conflicts: 12
shift/reduce). If someone can give a quick look then we will have a better
type definition syntax with ecpg.
*** postgresql-7.2.cvs/src/interfaces/ecpg/preproc/preproc.y Mon Mar 18
13:52:48 2002

--- postgresql-7.2/src/interfaces/ecpg/preproc/preproc.y Mon Mar 18 14:34:31
2002

***************

*** 169,174 ****

--- 169,175 ----

S_DOTPOINT S_EQUAL S_EXTERN S_INC S_LSHIFT S_MEMPOINT

S_MEMBER S_MOD S_MUL S_NEQUAL S_OR S_REGISTER S_RSHIFT

S_STATIC S_SUB S_VOLATILE

+ S_TYPEDEF

/* I need this and don't know where it is defined inside the backend */

%token TYPECAST

***************

*** 360,365 ****

--- 361,367 ----

%type <str> enum_type civar civarind ECPGCursorStmt ECPGDeallocate

%type <str> ECPGFree ECPGDeclare ECPGVar opt_at enum_definition

%type <str> struct_type s_struct declaration declarations
variable_declarations

+ %type <str> var_declaration type_declaration

%type <str> s_union union_type ECPGSetAutocommit on_off

%type <str> ECPGAllocateDescr ECPGDeallocateDescr symbol opt_symbol

%type <str> ECPGGetDescriptorHeader ECPGColLabel

***************

*** 3672,3678 ****

| declarations declaration { $$ = cat2_str($1, $2); }

;

! declaration: storage_clause storage_modifier

{

actual_storage[struct_level] = cat2_str(mm_strdup($1), mm_strdup($2));

actual_startline[struct_level] = hashline_number();

--- 3674,3749 ----

| declarations declaration { $$ = cat2_str($1, $2); }

;

! declaration: type_declaration { $$ = $1; }

! | var_declaration { $$ = $1; };

!

! type_declaration: S_TYPEDEF

! {

! /* reset this variable so we see if there was */

! /* an initializer specified */

! initializer = 0;

! }

! type opt_type_array_bounds opt_reference ColLabel ';'

! {

! /* add entry to list */

! struct typedefs *ptr, *this;

! int dimension = $4.index1;

! int length = $4.index2;

!

! if (($3.type_enum == ECPGt_struct ||

! $3.type_enum == ECPGt_union) &&

! initializer == 1)

! {

! mmerror(PARSE_ERROR, ET_ERROR, "Initializer not allowed in EXEC SQL VAR
command");

!

! }

! else

! {

! for (ptr = types; ptr != NULL; ptr = ptr->next)

!

!

!

!

!

!

! {

! if (strcmp($6, ptr->name) == 0)

! {

! /* re-definition is a bug */

! sprintf(errortext, "Type %s already defined", $6);

! mmerror(PARSE_ERROR, ET_ERROR, errortext);

! }

! }

!

! adjust_array($3.type_enum, &dimension, &length, $3.type_dimension,
$3.type_index, *$5?1:0);

!

! this = (struct typedefs *) mm_alloc(sizeof(struct typedefs));

!

! /* initial definition */

! this->next = types;

! this->name = $6;

! this->type = (struct this_type *) mm_alloc(sizeof(struct this_type));

! this->type->type_enum = $3.type_enum;

! this->type->type_str = mm_strdup($6);

! this->type->type_dimension = dimension; /* dimension of array */

! this->type->type_index = length; /* lenght of string */

! this->struct_member_list = ($3.type_enum == ECPGt_struct || $3.type_enum
== ECPGt_union) ?

! struct_member_list[struct_level] : NULL;

!

! if ($3.type_enum != ECPGt_varchar &&

! $3.type_enum != ECPGt_char &&

! $3.type_enum != ECPGt_unsigned_char &&

! this->type->type_index >= 0)

! mmerror(PARSE_ERROR, ET_ERROR, "No multi-dimensional array support for
simple data types");

!

! types = this;

! }

!

!

! $$ = cat_str(6, make_str("typedef "), mm_strdup($3.type_str),
mm_strdup($4.str), $5, mm_strdup($6), make_str(";"));

! };

!

! var_declaration: storage_clause storage_modifier

{

actual_storage[struct_level] = cat2_str(mm_strdup($1), mm_strdup($2));

actual_startline[struct_level] = hashline_number();

***************

*** 4260,4266 ****

types = this;

}

! $$ = cat_str(7, make_str("/* exec sql type"), mm_strdup($3),
make_str("is"), mm_strdup($5.type_str), mm_strdup($6.str), $7,
make_str("*/"));

}

;

--- 4331,4338 ----

types = this;

}

! // $$ = cat_str(7, make_str("/* exec sql type"), mm_strdup($3),
make_str("is"), mm_strdup($5.type_str), mm_strdup($6.str), $7,
make_str("*/"));

! $$ = cat_str(6, make_str("typedef "), mm_strdup($5.type_str),
mm_strdup($6.str), $7, mm_strdup($3), make_str(";"));

}

;

*** postgresql-7.2.cvs/src/interfaces/ecpg/preproc/c_keywords.c Mon Mar 18
13:52:48 2002

--- postgresql-7.2/src/interfaces/ecpg/preproc/c_keywords.c Mon Mar 18
14:00:41 2002

***************

*** 36,41 ****

--- 36,42 ----

{"signed", SQL_SIGNED},

{"static", S_STATIC},

{"struct", SQL_STRUCT},

+ {"typedef", S_TYPEDEF},

{"union", UNION},

{"unsigned", SQL_UNSIGNED},

{"varchar", VARCHAR},

----- Original Message -----
From: "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au>
To: "Michael Meskes" <meskes(at)postgresql(dot)org>
Cc: <pgsql-interfaces(at)postgresql(dot)org>
Sent: Monday, March 18, 2002 3:34 PM
Subject: Re: [INTERFACES] ecpg weird behavior

>
> ----- Original Message -----
> From: "Michael Meskes" <meskes(at)postgresql(dot)org>
> To: "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au>
> Cc: <pgsql-interfaces(at)postgresql(dot)org>
> Sent: Friday, March 15, 2002 7:21 PM
> Subject: Re: [INTERFACES] ecpg weird behavior
>
>
> > On Thu, Mar 14, 2002 at 05:16:41PM +1100, Nicolas Bazin wrote:
> > > It will know the variables when the cursor is declared. Here is the
> syntax
> > > that we currently use with INFORMIX and it also corresponds to the
> syntax in
> > > the PostgreSQL documentation:
> >
> > Where did you find this in the PostgreSQL docs?
> Ooops sorry I was refering to the documentation of the SQL commands in the
> reference manual, but I guess it is not fully relevent here.
>
> >
> > It certainly is not implemented.
> >
> > > EXEC SQL DECLARE curs_currency CURSOR FOR
> > > SELECT DISTINCT
> > > FT_devises.dvs_devise,pays.pys_coddevalp,pays.pys_nbrdecimal
> > > INTO :pays.pys_coddevnum, :pays.pys_coddevalp,
:pays.pys_nbrdecimal
> > > FROM pays, FT_devises WHERE FT_devises.dvs_code =
> :stpe.tpe_profdevise
> > > AND FT_devises.dvs_devise = pays.pys_coddevnum;
> > >
> > > EXEC SQL FETCH curs_currency;
> >
> > Anyone out there with more knowledge about standards? I thought this was
> > not standard at all.
> >
> > > > Yes, I am. Please send it to me directly at meskes(at)postgresql(dot)org(dot)
> > > This patch breaks backward compatibility. The idea was to change the
> output
> > > of the preproc when it parses EXEC SQL type mytpe is ... from comment
to
> the
> > > proper typedef definition. Then the typedef doesn't have to be added
> > > manually. If you still want it, I can send it.
> >
> > I still want it. After all I can change the behaviour with a command
> > line option.
>
> OK this patch includes the following (I hope it's in the right order this
> time):
> 1.
> EXEC SQL type mytype is .... does not need a typedef after.
> 2.
> EXEC SQL begin declare section;
> typedef struct {
> int field1;
> } mytype;
> mytype var1;
> EXEC SQL end declare sction;
>
> I still have a problem when the grammar is parsed by bison. I get the
> following message:
> conflicts: 12 shift/reduce
>
> As I told you before I'm not very familiar with yacc or bison so if you
> could help me in finding what is the problem.
>
> Nicolas BAZIN
>
> >
> > Michael
> > --
> > Michael Meskes
> > Michael(at)Fam-Meskes(dot)De
> > Go SF 49ers! Go Rhein Fire!
> > Use Debian GNU/Linux! Use PostgreSQL!
> >
>
>
>

Browse pgsql-interfaces by date

  From Date Subject
Next Message Thomas Lockhart 2002-03-20 03:46:04 Re: ecpg weird behavior
Previous Message Jeroen T. Vermeulen 2002-03-20 01:29:35 libpqxx: great renaming