On 15 April 2014 01:44, Blake McBride <blake1...@gmail.com> wrote:
> In terms of connecting to PostgreSQL (and probably most other 'real'
> databases), I think the connection string should have more (optional)
> arguments separated by a comma. The ones I use everyday with PostgreSQL
> are:
>
> driver=org.postgresql.Driver
> url=jdbc:postgresql:mydatabase
> user=userxyz
> password=thepassword
>
I'm using Kerberos for authentication everywhere, which is why I don't have
to include usernames or passwords in my connect strings, and all I had to
specify was the host name. Of course you can add whatever connect options
you want.
The way I've built the SQL support is simular to JDBC in a sense. You
specify the underlying database type (the argument to the left of the
connect command) and everything on the right-hand side is passed to the
backend. The SQLite backend only uses a single string (the file name) while
the Postgres one passes it as a conninfo string.
The conninfo strng is simply multiple parameters, separated by spaces where
each parameter is of the form key=value. In other words, something like
this:
'postgresql' SQL∆Connect "user=foo password=bar host=somehost"
>
> Of course this is an example from Java. C must have corresponding
> parameters. (I hope you are not _requiring_ an ODBC setup.)
>
No, I don't require ODBC. Although it wouldn't be hard to implement an ODBC
provider as well.
> The point being that you cannot connect to a database by just knowing
> where it is. You usually need a username and password so the database can
> determine your access permissions.
>
Only if you're not using Kerberos. :-)
But, like I said, using cleartext password in the connect sthing should
work perfectly fine. It's just that I don't normally use it myself.
> The driver option probably makes more sense for Java or if you are linking
> (via static library or shared library) to a native PostgreSQL library. But
> it can be useful if you are using runtime loading.
>
I'm not using any runtime loading for the driver. They are all linked into
the lib_sql.so library. The availability of the different database
libraries will probably be detected when running ./configure.
> I'm sorry, I actually came from the APL world and not the APL2 world
> (although I know what nested arrays are). I do not understand your SQL∆Select
> and SQL∆Exec lines do. Could you provide a brief explanation?
>
It's very simple. It's just a wrapper around the native variably entry
point. So, instead of typing:
* 'select * from foo where a=?' SQL[3,db] 10*
You'd simply type:
* 'select * from foo where a=?' SQL∆Select[db] 10*
It's imply implemented by a wrapper function like this:
∇Z←query SQL∆Select[dbId] args
Z←query SQL[3,dbId] args
∇
Thanks!
>
No problems.
Regards,
Elias
> Blake
>
>
>
> On Mon, Apr 14, 2014 at 11:25 AM, Elias Mårtenson <loke...@gmail.com>wrote:
>
>> Just an update: Postgres support almost works now. I have some issues
>> determining the correct data type of the returned values, but once that is
>> resolved it's time to work on the 2D array arguments.
>>
>> I've changed SQL[1] (connect) to accept a left argument, being the
>> database type. I will also make it register mnemonic functions so that you
>> don't have to see the function numbers. Thus, once the 2D stuff is ready
>> you'll be able to copy the content of "foo" in an SQLite database into
>> table "bar" in a Postgres database like this:
>>
>> 'libsql' ⎕FX 'SQL'
>>
>> dbA ← 'sqlite' SQL∆Connect '/path/to/database'
>> dbB ← 'postgresql' SQL∆Connect 'host=hostname.of.database.com'
>> result ← 'select * from foo' SQL∆Select[dbA] ⍬
>> 'insert into bar (a,b) values (?,?)' SQL∆Exec[dbB] result
>> SQL∆Close dbA
>> SQL∆Close dbB
>>
>>
>> Are you all OK with this syntax?
>>
>> Regards,
>> Elias
>>
>
>
