dbd-postgres: Make it possible to make safe queries

Hi Paolo,

these patches depend on the CObject patch you were creating earlier. My
problem is that I want to do queries with parameters that are not controlled
by me. I started to implement a Statement class (but without them being
prepared statements).

So the code is a bit better than before but still inferior to the SQLite
support. This code lacks prepared statements, lacks better binding support.

The last patch attempts to fix a type conversion of a NULL value.

regards
        holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Thanks!

I am only squashing this in:

diff --git a/packages/dbd-postgresql/Connection.st b/packages/dbd-postgresql/Connection.st
index 202e604..d2222ec 100644
--- a/packages/dbd-postgresql/Connection.st
+++ b/packages/dbd-postgresql/Connection.st
@@ -198,11 +198,11 @@ CObject subclass: PQConnection [
             ^ self error: 'All parameters must be strings here'].
 
         "Convert the params into an array of C-Strings."
-        par := CStringType new: params size.
+        ^[par := CStringType new: params size.
         1 to: params size do: [:each |
             par at: each - 1 put: (params at: each)].
 
-        [^ self
+        self
             exec_params:aSqlStatement
             n_par: params size
             types: nil
@@ -213,9 +213,9 @@ CObject subclass: PQConnection [
         ] ensure: [
             "Free the memory we allocated"
 
-            0 to: params size - 1 do: [:each |
-                (par derefAt: (each * CStringType sizeof) type: CObjectType) free
-            ].
+            par isNil ifFalse: [
+                0 to: params size - 1 do: [:each |
+                    ((par + each) derefAt: 0 type: CObjectType) free ].
 
             par free.
         ]

I'll probably add a utility method to CPtr for the derefAt:type: idiom.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 04/08/2011 03:24 PM, Paolo Bonzini wrote:
> Thanks!

Hi,
I have one more bugfix to make my code (first written for the SQLite backend)
work.

There is one more issue when going from DBD-SQLite to Postgres. I wonder if
the DBD-Sqlite code should call resetAndClear on a prepared query inside a
ensure block. Right now I call resetAndClear before doing the next query but
this is not available on the PGStatement. So I could either add it to the
Statement base class, or add the ensure to the SQLite Statement impl.


> I am only squashing this in:

With the merged code. Is there a gurantee that gcNew: N will initialize the
array with NULL? If not we might have an issue when an exception occurs when
filling the array.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 04/08/2011 03:24 PM, Paolo Bonzini wrote:
> Thanks!
>
> I am only squashing this in:
>

Hi Paolo,

the PQConnection is a CObject and does not inherit from Connection this means
the call to fieldConverter will fail. Now we could add a circular dependency
between PQConnection and the PQ subclass for Connection, create another
fieldSelector inside the PQConnection or do the type conversion in the
Statement. What do you think?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, Apr 9, 2011 at 00:15, Holger Hans Peter Freyther
<[hidden email]> wrote:
I'll add it to sqlite.

>> I am only squashing this in:
>
> With the merged code. Is there a gurantee that gcNew: N will initialize the
> array with NULL? If not we might have an issue when an exception occurs when
> filling the array.

Yes, gcNew is backed by a ByteArray.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk