That may work, but I am always leery of SQL with anything but straight,
printable ASCII. Plus, this has got to be a lot more CPU cycles. If you
can't implement the conversion between printable ASCII and APL arrays, I
can probably write some APL code that can translate between the strings you
do create (with arbitrary character sequences) and a (longer) string with
just printable ASCII (and no spaces). It would be unquestionably portable,
but would be slower.
Thanks.
Blake
On Sat, Apr 19, 2014 at 10:07 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi,
>
> I guess 10 ⎕CR is better suitable for that because it uses a portable
> subset of Unicode for APL values.
> I believe performance issues are a question of the past, so a little
> overhead is worth to be paid for
> simplicity. 10⎕CR output can be decoded with ⍎¨ for example:
>
>
>
>
>
>
>
>
>
> * ⎕←X←'Hello' 1 (2 3) Hello 1 2 3 ⎕←Y←10 ⎕CR 'X'
> X←3⍴0 X[0+⍳3]←'∘',1, 0 ((⎕IO+0)⊃X)←5⍴'Hello' ((⎕IO+2)⊃X)←2⍴2,3
> )ERASE X 0⍴ ⍎¨Y X Hello 1 2 3 *
> /// Jürgen
>
>
>
>
>
> On 04/19/2014 04:43 PM, Elias Mårtenson wrote:
>
> You are right. The SQL implementation uses C strings behind the scenes for
> both SQLite and Postgres.
>
> I'll be happy to implement BLOB support if you can suggest a good syntax
> for it from APL.
>
> Regards,
> Elias
>
>
> On 19 April 2014 22:34, Blake McBride <blake1...@gmail.com> wrote:
>
>> Looks good. I am a little concerned that the vector produced by 3 ⎕TF
>> may have trouble going to and from an SQL VARCHAR using the existing (and
>> fantastic!) library. I am not sure, but there may be a problem with C null
>> characters ('\0') or other non-printable characters. Some feedback on this
>> would be very helpful.
>>
>> Thanks!
>>
>> Blake
>>
>>
