«

Nicolao <> wrote:

> In article <>, Richard Bos
> <> wrote:
>
> > And this is really just one error message, plus the result of it. The
> > real error is that you haven't defined PQgetvalues() - make sure that's
> > the correct spelling of the name. The result of this is that you don't
> > have a declaration for it, either, so the compiler is required to assume
> > that it returns an int - but then you assign it to a pointer, without a
> > cast. For the correct spelling of the name, with a correct declaration,
> > this is probably correct - but not for the automatic declaration of the
> > incorrect name.
>
> Whoops, thrashing about here, am I not. And, however I correct what
> I've done, I still get some kind of error. The problem - with this
> being a rehash of someone else's program - is there's too much I don't
> understand yet, like why none of those PQ* doodads is formally
> declared, whereas the PG* ones are.

But they are - if they weren't, the compiler would have complained about
several of them, not just about the one you misspelled. They're probably
declared in that non-Standard header you #include. (And so, one
presumes, are the PG* types.)

Richard

In article <>, Richard Bos
<> wrote:

> Nicolao <> wrote:
>
> > In article <>, Richard Bos
> > <> wrote:
> >
> > > And this is really just one error message, plus the result of it. The
> > > real error is that you haven't defined PQgetvalues() - make sure that's
> > > the correct spelling of the name. The result of this is that you don't
> > > have a declaration for it, either, so the compiler is required to assume
> > > that it returns an int - but then you assign it to a pointer, without a
> > > cast. For the correct spelling of the name, with a correct declaration,
> > > this is probably correct - but not for the automatic declaration of the
> > > incorrect name.
> >
> > Whoops, thrashing about here, am I not. And, however I correct what
> > I've done, I still get some kind of error. The problem - with this
> > being a rehash of someone else's program - is there's too much I don't
> > understand yet, like why none of those PQ* doodads is formally
> > declared, whereas the PG* ones are.
>
> But they are - if they weren't, the compiler would have complained about
> several of them, not just about the one you misspelled. They're probably
> declared in that non-Standard header you #include. (And so, one
> presumes, are the PG* types.)
>
> Richard

Thanks Richard,

I've since opened up the libpq-fe.h file and found it full of stuff -
some of which makes sense, even to my unprogrammed mind. However, I'm
beginning to question whether C is the most appropriate langauge to use
for this particular task. It's a hard guess to make, when you have so
little ground knowledge. For example, Perl & Python are built-ins for
postgreSQL, and some tutorial pages I've accessed suggest Python deals
with strings in a more adaptable manner.

Perhaps I should explain the task. What I need my program to do is:
convert a linear steam of text (one sentence at a time) into a group of
syntactical units, their purpose in the sentence, and the relationships
they have to each other, coded from data stored in a postgreSQL
backend.

In the db, each 'word' has a codestring which contains a detailed
syntactical analysis. So I'm going to need a language which will 1)
readily fetch those codestrings from the db and place them alongside
their 'words', and 2) be easily splitable into segments (e.g. the 1st
character of the string might determine whether the word is a noun, and
the 2nd, whether that noun is singular or plural - etc).

Now - I've really enjoyed my learning of C, but now I get to this
specific area of useage, it seems suddenly to be counter-intuitive to
work with, and present me with a whole ladder of steps where I'd
expected one (i.e. get data from one place, stick it in another). Now
that MAY mean that I have heaps more to learn (which is fine), but it
might ALSO mean I am - in my innocence and ignorance - using the wrong
tool for the job.

Any thoughts? Or, if this is an inappropriate question here, any
nominations for the best group to ask that question.

Nic

Nicolao <> wrote:

> In article <>, Richard Bos
> <> wrote:
>
> > Nicolao <> wrote:
> >
> > > In article <>, Richard Bos
> > > <> wrote:
> > >
> > > > And this is really just one error message, plus the result of it. The
> > > > real error is that you haven't defined PQgetvalues() - make sure that's
> > > > the correct spelling of the name. The result of this is that you don't
> > > > have a declaration for it, either, so the compiler is required to assume
> > > > that it returns an int - but then you assign it to a pointer, without a
> > > > cast. For the correct spelling of the name, with a correct declaration,
> > > > this is probably correct - but not for the automatic declaration of the
> > > > incorrect name.
> > >
> > > Whoops, thrashing about here, am I not. And, however I correct what
> > > I've done, I still get some kind of error. The problem - with this
> > > being a rehash of someone else's program - is there's too much I don't
> > > understand yet, like why none of those PQ* doodads is formally
> > > declared, whereas the PG* ones are.
> >
> > But they are - if they weren't, the compiler would have complained about
> > several of them, not just about the one you misspelled. They're probably
> > declared in that non-Standard header you #include. (And so, one
> > presumes, are the PG* types.)
>
> I've since opened up the libpq-fe.h file and found it full of stuff -
> some of which makes sense, even to my unprogrammed mind.

Don't worry - most of the time you don't need to bother with the details
of what's in those header files. All you need to know is _what_ is
declared in a header (i.e., which types, which functions); _as_ what
they are declared (i.e., as a function taking two ints and returning a
char *, as a struct with such-and-such members, as an opaque type which
you can pass to library functions but need not examine in depth, and so
forth); but rarely exactly _how_ they are declared (or defined, in the
case of types and macros).
What's more, you shouldn't need to get this information from the header
file itself. There should be some form of documentation with the library
detailing what it provides. That is a necessity if only because you
can't actually use its functions without knowing what it does.

> However, I'm beginning to question whether C is the most appropriate
> langauge to use for this particular task.

That's impossible for me to say without in-depth knowledge of the
project, but using C for a database project is far from unheard-of.

> Perhaps I should explain the task. What I need my program to do is:
> convert a linear steam of text (one sentence at a time) into a group of
> syntactical units, their purpose in the sentence, and the relationships
> they have to each other,

This is natural language processing? There are languages that try to
cater specifically to such tasks. Have you seen Snobol or Icon?

> In the db, each 'word' has a codestring which contains a detailed
> syntactical analysis. So I'm going to need a language which will 1)
> readily fetch those codestrings from the db and place them alongside
> their 'words', and 2) be easily splitable into segments (e.g. the 1st
> character of the string might determine whether the word is a noun, and
> the 2nd, whether that noun is singular or plural - etc).

Both are entirely possible in C, but might be easier in specialist
languages. I wouldn't require Perl unless you like reading line noise,
though :-/

Richard

In article <>, Richard Bos
<> wrote:

[snip]

> This is natural language processing? There are languages that try to
> cater specifically to such tasks. Have you seen Snobol or Icon?
>
> > In the db, each 'word' has a codestring which contains a detailed
> > syntactical analysis. So I'm going to need a language which will 1)
> > readily fetch those codestrings from the db and place them alongside
> > their 'words', and 2) be easily splitable into segments (e.g. the 1st
> > character of the string might determine whether the word is a noun, and
> > the 2nd, whether that noun is singular or plural - etc).
>
> Both are entirely possible in C, but might be easier in specialist
> languages. I wouldn't require Perl unless you like reading line noise,
> though :-/
>
> Richard

Thanks Richard

I'll certainly check out Snobol & Icon, but I'd prefer it to be
possible in C, as so far I've enjoyed my little experiments. So I
reckon to stick at it.

Thanks for your help

Nic

Nicolao wrote:
> In article <>, Richard Bos
> <> wrote:
>
> [snip]
>
>
>>This is natural language processing? There are languages that try to
>>cater specifically to such tasks. Have you seen Snobol or Icon?
>>
>>
>>>In the db, each 'word' has a codestring which contains a detailed
>>>syntactical analysis. So I'm going to need a language which will 1)
>>>readily fetch those codestrings from the db and place them alongside
>>>their 'words', and 2) be easily splitable into segments (e.g. the 1st
>>>character of the string might determine whether the word is a noun, and
>>>the 2nd, whether that noun is singular or plural - etc).
>>
>>Both are entirely possible in C, but might be easier in specialist
>>languages. I wouldn't require Perl unless you like reading line noise,
>>though :-/
>>
>>Richard
>
>
> Thanks Richard
>
> I'll certainly check out Snobol & Icon, but I'd prefer it to be
> possible in C, as so far I've enjoyed my little experiments. So I
> reckon to stick at it.
>
> Thanks for your help
>
> Nic

Perhaps this has already been posted, and I missed it, but

http://www.postgresql.org/docs/7.4/static/index.html

has some pretty comprehensive documentation. Chapter 27 deals
specifically with the C interface to PostgreSQL.

What you are trying to do is not that difficult, and from what I have
read you're getting closer.

And, while it is probably beyond the scope here, a word to the wise --
if the program is not just for YOUR general use, it is always a good
idea to either escape the input you get via your scanf (PQescapeString
is the call I believe), or else use prepared queries to avoid SQL
injection attacks. But again, probably beyond the scope until you get
your basic functionality up and running....

Hope this helps a bit,
Frank

In article <cYFHd.57167$Wo.27172@lakeread08>, Frank Way
<> wrote:

> Perhaps this has already been posted, and I missed it, but
>
> http://www.postgresql.org/docs/7.4/static/index.html
>
> has some pretty comprehensive documentation. Chapter 27 deals
> specifically with the C interface to PostgreSQL.
>
> What you are trying to do is not that difficult, and from what I have
> read you're getting closer.
>
> And, while it is probably beyond the scope here, a word to the wise --
> if the program is not just for YOUR general use, it is always a good
> idea to either escape the input you get via your scanf (PQescapeString
> is the call I believe), or else use prepared queries to avoid SQL
> injection attacks. But again, probably beyond the scope until you get
> your basic functionality up and running....
>
> Hope this helps a bit,
> Frank

Thanks Frank, I got my original blueprint from such a source - if not
actually that one. Your comments reminded me to look again, and perhaps
you are right and I am "getting closer", for on the whole what I saw
seemed far less 'mystical' than before! However, this may not be
sufficient basis for a general theory of 'progress' :=)

I dare say if I get this idea running, I shall be inputting &
outputting via files, rather than working with scanf input. SQL
injections sound a last resort! I'll try to stick to gradual
absorption of C. Fortunately I like oranges.

Thanks again for yet more helpful advice. I've certainly come to the
right place.

Nic