Re: [gnome-db] Patch Postgres provider.

[Bas Driessen <bas driessen xobas com>]

On Thu, 2004-10-28 at 07:58, Daniel Espinosa wrote:
>  --- Vivien Malerba <vmalerba gmail com> escribió: 
> > On Wed, 27 Oct 2004 23:00:11 +1000, Bas Driessen
> > <bas driessen xobas com> wrote:
> > >  On Wed, 2004-10-27 at 18:53, Vivien Malerba
> > wrote: 
> > > 
> > > 
> > >  On Wed, 27 Oct 2004 16:52:30 +1000, Bas Driessen
> > <bas driessen xobas com>
> > > wrote: > Hello, > > Attached a patch for the
> > postgres provider. I can't find
> > > any "patch > instructions" on your web pages, so
> > not sure about the
> > > procedure, so please > advise if it is not conform
> > the rules. > > Anyway,
> > > when using gda_data_model_append_row and a column
> > name is a > reserved name
> > > like "desc" or "typeid", the INSERT query is
> > unsuccessful and > returns an
> > > error. What this patch does is place " arround the
> > column names. > So: > >
> > > INSERT INTO parts(part_id, desc, price) VALUES
> > (123, 'Test', 12.34) > >
> > > becomes > > INSERT INTO parts("part_id", "desc",
> > "price") VALUES (123,
> > > 'Test', 12.34) > > and all works fine. > > Sure,
> > it is probably not a good
> > > idea to use reserved names for column > names, but
> > people will be using them
> > > not knowing that some names are > special. > >
> > Thanks, > Bas. > Seems ok for
> > > me; I'll commit it to CVS soon. Vivien 
> > >  Thanks Vivien, I noticed that the problem is in
> > the
> > > gda_data_model_update_row area as well. Attached
> > another patch file, that
> > > should be applied after the previous one. However,
> > there is a small problem
> > > and I don't have enough understanding of
> > g_strdup_printf to resolve it, so
> > > hope you (or anyone else) can help.
> > >  
> > >  This is the solution we need:
> > >  
> > >  tmp = g_strdup_printf ("\"%s\" = '%s', ",
> > >                                                
> > column_name,
> > >                                                
> > newval);
> > >  
> > >  However, g_strdup_printf does not allow to have
> > \" as the first character
> > > and the function gda_data_model_update_row fails
> > with a segmentation fault.
> > > I can change \" to any other character, put
> > another character in front of it
> > > (except space, tab etc) or leave it out and it
> > works, but as soon as the
> > > first char is \" it fails. Why??
> > >  
> > >  If you have seen this before and if there is a
> > very simple solution to
> > > this, please advise. Otherwise we have to
> > "re-wire" this function a bit.
> > >  
> > 
> > I'll try to have a look at that problem...
> > 
> > Thanks for the patch,
> > 
> > Vivien
> > _______________________________________________
> > gnome-db-list mailing list
> > gnome-db-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-db-list
> >  
>
>
> Which version of glib do you have?
>
> This is becouse I have a program tested with gnome-db
> 1.1.99 with the following lines:
>
> str = g_strdup_printf("Sel: %i; Texto:\"%s\"",
> gtk_combo_box_get_active(combo),gtk_entry_get_text(GTK_ENTRY
> (GTK_BIN (combo)->child)));
> 	
> gtk_entry_set_text(GTK_ENTRY(entry),str);
>
> And as you see I using \" to have a string between "",
> and it works with out problem.

Hi Daniel,

To answer your question, my version of glib(s) are glib2:2.4.7, glib:1.2.10, glibc:2.3.3 However, I have been investigating further and the problem is not related to g_strdup_printf. It falls over the following line in gda_postgres_recordset_update_row:

status = GDA_DATA_MODEL_CLASS (parent_class)->update_row (model, row);

I am not sure what this line does or where it is jumping to. Would appreciate if somebody can give me a hint where in code to continue my search.

The top of the gdb backtrace is as follows:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1084225888 (LWP 4935)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000002a95d36db4 in gda_postgres_recordset_update_row (model=0x5569e0, row=0x5815e0) at gda-postgres-recordset.c:451
#2  0x0000002a95681f76 in gda_data_model_update_row (model=0x5569e0, row=0x5815e0) at gda-data-model.c:724

As you can see not much help in step #0. 

I must say btw, that the database gets updated OK, so it is in the last couple of steps (cleanup?) that something goes wrong. Great functionality these recordset functions, so would love to get them to work.

Thanks,
Bas.