Michael Meskes írta:
> On Fri, Aug 07, 2009 at 11:48:33AM +0200, Boszormenyi Zoltan wrote:
>
>> Which isn't exactly a good programming habit.
>>
>
> I couldn't agree more.
>
:-)
>> In the above code local, in-scope variables are also replaced
>> with ECPG_informix_set_var() and _get_va
On Fri, Aug 07, 2009 at 11:48:33AM +0200, Boszormenyi Zoltan wrote:
> Which isn't exactly a good programming habit.
I couldn't agree more.
> In the above code local, in-scope variables are also replaced
> with ECPG_informix_set_var() and _get_var() calls.
> Totally unnecessary, or totally necessa
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 04:22:53PM +0200, Boszormenyi Zoltan wrote:
>
>> If you meant like this below, then ECPG segfaults on this too:
>>
>
> Right, because arrays as as well unimplemented as are structs. I meant
> something like this;
>
> int *
> get_var(void)
> {
>
On Wed, Aug 05, 2009 at 04:22:53PM +0200, Boszormenyi Zoltan wrote:
> If you meant like this below, then ECPG segfaults on this too:
Right, because arrays as as well unimplemented as are structs. I meant
something like this;
int *
get_var(void)
{
EXEC SQL BEGIN DECLARE SECTION;
st
Boszormenyi Zoltan írta:
> Michael Meskes írta:
>
>> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>>
>>
>>> I have looked at it. The code seems to be invalid.
>>>
>>>
>> Yes, it is, I was too lazy to make it valid. If you just allocate the memory
>> for
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 03:04:00PM +0200, Boszormenyi Zoltan wrote:
>
>> My question is: why not unroll the struct in the preprocessor?
>>
>
> The problem is not that the struct is unrolled in the preprocessor. I just
> don't like the idea of having two places where s
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>
>> I have looked at it. The code seems to be invalid.
>>
>
> Yes, it is, I was too lazy to make it valid. If you just allocate the memory
> for the variable in get_var() it becomes valid.
>
If y
On Wed, Aug 05, 2009 at 03:04:00PM +0200, Boszormenyi Zoltan wrote:
> My question is: why not unroll the struct in the preprocessor?
The problem is not that the struct is unrolled in the preprocessor. I just
don't like the idea of having two places where structs are unrolled when one
could be suff
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:52:57AM +0200, Boszormenyi Zoltan wrote:
>
>> This means that what I did in my first patch for this
>> problem in "add_struct_to_head()" (unrolling members
>> of the struct) has to be done in adjust_informix(),
>> turning it into a recursive func
On Wed, Aug 05, 2009 at 11:52:57AM +0200, Boszormenyi Zoltan wrote:
> This means that what I did in my first patch for this
> problem in "add_struct_to_head()" (unrolling members
> of the struct) has to be done in adjust_informix(),
> turning it into a recursive function.
> I think this would be a
Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
>
>> I have looked at it. The code seems to be invalid.
>>
>
> Yes, it is, I was too lazy to make it valid. If you just allocate the memory
> for the variable in get_var() it becomes valid.
>
With
On Wed, Aug 05, 2009 at 11:08:26AM +0200, Boszormenyi Zoltan wrote:
> I have looked at it. The code seems to be invalid.
Yes, it is, I was too lazy to make it valid. If you just allocate the memory
for the variable in get_var() it becomes valid.
> I tried to compile your code (with my previous "f
Michael Meskes írta:
> On Fri, Jul 31, 2009 at 11:42:33AM +0200, Boszormenyi Zoltan wrote:
>
>> made me look around more. Find the attached patch I came up with.
>> Now my previous test code works and produces similar C code
>> as without "-C INFORMIX". Can it be this simple?
>>
>
> Unfortu
On Fri, Jul 31, 2009 at 11:42:33AM +0200, Boszormenyi Zoltan wrote:
> made me look around more. Find the attached patch I came up with.
> Now my previous test code works and produces similar C code
> as without "-C INFORMIX". Can it be this simple?
Unfortunately it is not.
> Can you see anything
Michael Meskes írta:
> On Fri, Jul 17, 2009 at 03:58:21PM +0200, Boszormenyi Zoltan wrote:
>
>> Attached is the short example I can reproduce with.
>> The version I used was final PostgreSQL 8.4.0, without our
>> extensions posted already. I added an indication to ecpg_type_name():
>>
>> [z...@d
On Fri, Jul 17, 2009 at 03:58:21PM +0200, Boszormenyi Zoltan wrote:
> Attached is the short example I can reproduce with.
> The version I used was final PostgreSQL 8.4.0, without our
> extensions posted already. I added an indication to ecpg_type_name():
>
> [z...@db00 ecpg-test]$ ecpg -C INFORMIX
Michael Meskes írta:
> On Fri, Jul 17, 2009 at 12:27:49PM +0200, Boszormenyi Zoltan wrote:
>
>> one of our clients wants to port their application suite
>> from Informix to PostgreSQL, they use constructs like
>>
>> SELECT * INTO :tablerec FROM table ...
>>
>> where "tablerec" mirrors the table
On Fri, Jul 17, 2009 at 12:27:49PM +0200, Boszormenyi Zoltan wrote:
> one of our clients wants to port their application suite
> from Informix to PostgreSQL, they use constructs like
>
> SELECT * INTO :tablerec FROM table ...
>
> where "tablerec" mirrors the table fields in a C struct.
Well, thi
Hi,
one of our clients wants to port their application suite
from Informix to PostgreSQL, they use constructs like
SELECT * INTO :tablerec FROM table ...
where "tablerec" mirrors the table fields in a C struct.
Currently ECPG dumps core on this, more exactly aborts on it
in ecpg_type_name().
P
19 matches
Mail list logo
