Re: [SQL] libpq-fe: PQgetvalue() ?

2004-10-15 Thread Christoph Haller
AFAIK it does allocate memory.
You cannot PQclear(pgresult_varible) while cstring_varible is in use.
You do not need to free cstring_variable, PQclear(pgresult_varible) will do.
I personally prefer to allocate local memory, "strcpy" PQgetvalue,
and then PQclear. But that's a matter of taste, I suppose.

Regards, Christoph


sad wrote:

> hi
>
> does PQgetvalue() allocate memory rof its result, it returns ?
> the answer will help me in problem:
> should i free some cstring_variable if
> { cstring_variable=PQgetvalue(pgresult_variable,0,0); }
> and could i PQclear(pgresult_varible) while cstring_varible is in use.
>
> thnx
>


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [SQL] Inserting into table only if the row does not already

2004-10-15 Thread C. Bensend

> You just have to put it in the select list as a constant. If you're
> feeling
> generous to the next programmer to read it you could put "AS column1"
> after
> each one, but the column name doesn't actually have to match the column
> you're
> inserting into.

Sweet GOD, I hope no one ever has to read the stuff I'm working on!

This is just a personal curiousity project, not anything for work or
anything released publicly.  I'd be far too embarrassed to ever release
this, as I'm just fumbling along, learning.  :)

> Note that this is going to have some concurrency issues. I think it will
> be
> possible for a second query to execute before the first commits. In that
> case
> it won't see the record the first query inserted and try to insert again.
> You'll just get a primary key violation though which I guess you can just
> ignore.

Concurrency shouldn't be an issue - this is a perl script running from
cron.  The only concurrency that will ever happen is if I'm a bonehead
and I run the script manually right as cron kicks off another copy.

> Which raises a question. Why not forgoe this complicated SQL and try to do
> the
> insert. If you get a primary key violation, well there's your answer... If
> you
> don't care about the failure just ignore it and move on. I would suggest
> checking specifically for a primary key violation and still stopping
> execution
> on unexpected errors though.

Well, I was hoping to minimize the amount of perl needed to get this one
task done, but I think that's going to be the best way to do it.

> Incidentally, if you're putting your parameters directly into your queries
> using $column1 then you've got a potential security problem. Unless you're
> quoting every variable everywhere religiously using postgres's quoting
> functions an attacker can sneak extra SQL into your queries. Potentially
> including whole new statements such as "DELETE FROM table"...

Yes indeed, good catch.  I'll clean that up immediately.

Thanks, Greg!

Benny


-- 
"Even if a man chops off your hand with a sword, you still have two nice,
sharp bones to stick in his eyes."
  -- .sig on Slashdot




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [SQL] libpq-fe: PQgetvalue() ?

2004-10-15 Thread Tom Lane
Christoph Haller <[EMAIL PROTECTED]> writes:
> You cannot PQclear(pgresult_varible) while cstring_varible is in use.
> You do not need to free cstring_variable, PQclear(pgresult_varible) will do.
> I personally prefer to allocate local memory, "strcpy" PQgetvalue,
> and then PQclear. But that's a matter of taste, I suppose.

That is surely overkill.

PQgetvalue doesn't allocate new memory for its result.  The docs are
reasonably clear, I thought:

 The pointer returned by PQgetvalue points to storage that is part
 of the PGresult structure. One should not modify the data it points
 to, and one must explicitly copy the data into other storage if it
 is to be used past the lifetime of the PGresult structure itself.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html