Re: Getting started - Interfacing questions

On Mar 8, 2005, at 10:07 AM, David wrote:

> This came to me privately but not to the list.

Oops, my bad.

> On Tue, Mar 08, 2005 at 06:15:18AM -0500, Sean Davis wrote:
>> I didn't mean to complicate things.
>
> You didn't, really. What I'm trying to do is to see all my options
> before I get too deeply involved in a certain path.
>
>> If all you are doing is a few
>> inserts a day at home, just use pgAdmin III and add rows to the tables
>> as you see fit. I like using web-based front-ends to my databases,
>> but
>> that is just me and I (and users of my databases) have specific
>> hardware (multiple platforms, extremely varied performance) and
>> software (I do have apache available) constraints and requirements.
>
> My goal is to try to get a decent setup within reason. In great part,
> it's basically a learning experience. What I'm doing here is of no
> great import. It will never be something that will be worth sharing
> either commercially or even as an open source thing.

> As far as the inputting of data goes, as I said, it would not be a
> tremendous inconvenience to do my INSERT's, etc, with SQL commands, but
> I'd have to remember the field names for a straight INSERT, or remember
> the order for the parameters if I do it through a function. Probably
> the simplest solution would be to write a specific app, but actually,
> what I was originally wondering was if I could perhaps run from psql
> and
> then call a PL function, perhaps in plperl or whatever, that would put
> up a form and then either insert the record or return the record
> generated. However, I saw some mention in the mailing list that you
> cannot get input from within a function?
>>

Getting input is the realm of the client application, not the server,
generally, yes.

>> The point of my last email is that there are many ways to accomplish
>> what you are proposing and the only "best" one is the one that teaches
>> you what you want to learn, accomplishes the goals of the project, and
>> has room and flexibility for extension and growth when and where you
>> need it. Whatever route you choose will have specifics associated
>> with
>> it, some requiring more learning than others.
>
> Exactly. What I'm seeing is that there are so many ways to go about
> it,
> and numerous languages that will get the job done. And when it comes
> to
> making the decision upon which language, etc, it's something that no
> one
> can really tell me.
>
> Actually, my original question might resolve to this. It appears that
> there are two ways to go about it.. You can start from within SQL, and
> work "outward", so to speak, using functions to do your work. This
> would be the case with psql and perhaps the general front-ends.
> Alterantively, you can start from the "outside" and work "inward".
> That
> would be to create an application written in "C", perl, python, php, or
> whatever, and then do your database work using the calls provided with
> the language. Is this a reasonable assessment?
>

Actually, all database transactions, etc., will rely on SQL to a large
degree. I would start with pgAdmin III, as it will graphically allow
you to interact with your database. Alternatively, you can use pgEdit
(a nice tool with many of the benefits of psql), but you will write .
That is likely all that you will need. Then, you can go about choosing
the language, API, tool that you can experiment to your heart's
content. Working with databases is quite well-worked-out for most of
the higher languages (including C), so you really just need to pick one
and start learning how to go about interacting with the database in
that language. There are typically numerous websites of a tutorial
nature for building database-based scripts/programs/tools. So, you
will have to commit to something and then let us know when you get hung
up.

Sean