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!
> >
>
>
>
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 |