C API, PQconnectdb and options Q.

[D. Stimits]

I'm using a Redhat version of PostgreSQL 7.2.3 with the C API. Mostly
things work right, but I need more debug output, as I have a query that
works fine from psql, but fails with the C API (perhaps this is because
I use PQescapeString) . The only way to know there is an error is that
the insert never happens, and that the system log reports a parse error
at or near the first field of an insert. What I am wonder is (a) how to
use the tty= in the string passed to PQconnectdb, and (b) a reference
URL for what options are available in the options= part of the string
parameters accepted by PQconnectdb. So far all I end up with if I try to
name a file for tty= or a tty from /dev/ for tty= is a core dump.

D. Stimits


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

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

[D. Stimits]

Re: C API, PQconnectdb and options Q.

D. Stimits wrote:
[color=blue]
> I'm using a Redhat version of PostgreSQL 7.2.3 with the C API. Mostly
> things work right, but I need more debug output, as I have a query that
> works fine from psql, but fails with the C API (perhaps this is because
> I use PQescapeString) . The only way to know there is an error is that
> the insert never happens, and that the system log reports a parse error
> at or near the first field of an insert. What I am wonder is (a) how to
> use the tty= in the string passed to PQconnectdb, and (b) a reference
> URL for what options are available in the options= part of the string
> parameters accepted by PQconnectdb. So far all I end up with if I try to
> name a file for tty= or a tty from /dev/ for tty= is a core dump.
>
> D. Stimits
>[/color]
I found a partial answer to this...it seems to be a bug in
PQescapeString( ). Turns out that if I do something with an insert using
quotes for a varchar field, e.g.:
INSERT INTO foo VALUES ('bar')

....then it escapes this to:
INSERT INTO foo VALUES (''bar'')

It doesn't like the pair of single quotes.

But I also can't do this, due to requirements of SQL syntax:
INSERT INTO foo VALUES (bar)

How can I use PQescapeString( ) with input I would like to make somewhat
safer via escaping? How would I use PQescapeString( ) without writing my
own replacement that works with inserts?

D. Stimits


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Richard Huxton]

Re: C API, PQconnectdb and options Q.

On Wednesday 10 September 2003 18:47, D. Stimits wrote:[color=blue]
>
> I found a partial answer to this...it seems to be a bug in
> PQescapeString( ). Turns out that if I do something with an insert using
> quotes for a varchar field, e.g.:
> INSERT INTO foo VALUES ('bar')
>
> ...then it escapes this to:
> INSERT INTO foo VALUES (''bar'')
>
> It doesn't like the pair of single quotes.
>
> But I also can't do this, due to requirements of SQL syntax:
> INSERT INTO foo VALUES (bar)
>
> How can I use PQescapeString( ) with input I would like to make somewhat
> safer via escaping? How would I use PQescapeString( ) without writing my
> own replacement that works with inserts?[/color]

I think the idea is to escape just the parameters to the SQL statement. So
(not in C syntax):

query = "INSERT INTO foo values ('" + PQescapeString( "O'Neill") + "')"

This will double the single-quote in O'Neill.

I tend to use higher-level languages where this sort of thing is handled by
functions in e.g. Perl's DBI layer. If there isn't a suitable interface layer
available, you could write your own that does something like:

query = build_sql("INSE RT INTO foo values (?,'?')", 1, "fred");

I can't believe there isn't something like this available though.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Stephan Szabo]

Re: C API, PQconnectdb and options Q.

On Wed, 10 Sep 2003, D. Stimits wrote:
[color=blue]
> D. Stimits wrote:
>[color=green]
> > I'm using a Redhat version of PostgreSQL 7.2.3 with the C API. Mostly
> > things work right, but I need more debug output, as I have a query that
> > works fine from psql, but fails with the C API (perhaps this is because
> > I use PQescapeString) . The only way to know there is an error is that
> > the insert never happens, and that the system log reports a parse error
> > at or near the first field of an insert. What I am wonder is (a) how to
> > use the tty= in the string passed to PQconnectdb, and (b) a reference
> > URL for what options are available in the options= part of the string
> > parameters accepted by PQconnectdb. So far all I end up with if I try to
> > name a file for tty= or a tty from /dev/ for tty= is a core dump.
> >
> > D. Stimits
> >[/color]
> I found a partial answer to this...it seems to be a bug in
> PQescapeString( ). Turns out that if I do something with an insert using
> quotes for a varchar field, e.g.:
> INSERT INTO foo VALUES ('bar')
>
> ...then it escapes this to:
> INSERT INTO foo VALUES (''bar'')[/color]

I don't think you're using it correctly...
"PQescapeSt ring escapes a string for use within an SQL commmand."
....
"The single quotes that must surround PostgreSQL string literals are not
included in the result string; they should be provided in the SQL
command that the result is inserted into."

The intent is not for PQescapeString to take a query string, but a
string for use within a query string (for example, the literal bar in the
above).


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[D. Stimits]

Re: C API, PQconnectdb and options Q.

D. Stimits wrote:
[color=blue]
> I'm using a Redhat version of PostgreSQL 7.2.3 with the C API. Mostly
> things work right, but I need more debug output, as I have a query that
> works fine from psql, but fails with the C API (perhaps this is because
> I use PQescapeString) . The only way to know there is an error is that
> the insert never happens, and that the system log reports a parse error
> at or near the first field of an insert. What I am wonder is (a) how to
> use the tty= in the string passed to PQconnectdb, and (b) a reference
> URL for what options are available in the options= part of the string
> parameters accepted by PQconnectdb. So far all I end up with if I try to
> name a file for tty= or a tty from /dev/ for tty= is a core dump.
>
> D. Stimits
>[/color]
I found a partial answer to this...it seems to be a bug in
PQescapeString( ). Turns out that if I do something with an insert using
quotes for a varchar field, e.g.:
INSERT INTO foo VALUES ('bar')

....then it escapes this to:
INSERT INTO foo VALUES (''bar'')

It doesn't like the pair of single quotes.

But I also can't do this, due to requirements of SQL syntax:
INSERT INTO foo VALUES (bar)

How can I use PQescapeString( ) with input I would like to make somewhat
safer via escaping? How would I use PQescapeString( ) without writing my
own replacement that works with inserts?

D. Stimits


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Richard Huxton]

Re: C API, PQconnectdb and options Q.

On Wednesday 10 September 2003 18:47, D. Stimits wrote:[color=blue]
>
> I found a partial answer to this...it seems to be a bug in
> PQescapeString( ). Turns out that if I do something with an insert using
> quotes for a varchar field, e.g.:
> INSERT INTO foo VALUES ('bar')
>
> ...then it escapes this to:
> INSERT INTO foo VALUES (''bar'')
>
> It doesn't like the pair of single quotes.
>
> But I also can't do this, due to requirements of SQL syntax:
> INSERT INTO foo VALUES (bar)
>
> How can I use PQescapeString( ) with input I would like to make somewhat
> safer via escaping? How would I use PQescapeString( ) without writing my
> own replacement that works with inserts?[/color]

I think the idea is to escape just the parameters to the SQL statement. So
(not in C syntax):

query = "INSERT INTO foo values ('" + PQescapeString( "O'Neill") + "')"

This will double the single-quote in O'Neill.

I tend to use higher-level languages where this sort of thing is handled by
functions in e.g. Perl's DBI layer. If there isn't a suitable interface layer
available, you could write your own that does something like:

query = build_sql("INSE RT INTO foo values (?,'?')", 1, "fred");

I can't believe there isn't something like this available though.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Stephan Szabo]

Re: C API, PQconnectdb and options Q.

On Wed, 10 Sep 2003, D. Stimits wrote:
[color=blue]
> D. Stimits wrote:
>[color=green]
> > I'm using a Redhat version of PostgreSQL 7.2.3 with the C API. Mostly
> > things work right, but I need more debug output, as I have a query that
> > works fine from psql, but fails with the C API (perhaps this is because
> > I use PQescapeString) . The only way to know there is an error is that
> > the insert never happens, and that the system log reports a parse error
> > at or near the first field of an insert. What I am wonder is (a) how to
> > use the tty= in the string passed to PQconnectdb, and (b) a reference
> > URL for what options are available in the options= part of the string
> > parameters accepted by PQconnectdb. So far all I end up with if I try to
> > name a file for tty= or a tty from /dev/ for tty= is a core dump.
> >
> > D. Stimits
> >[/color]
> I found a partial answer to this...it seems to be a bug in
> PQescapeString( ). Turns out that if I do something with an insert using
> quotes for a varchar field, e.g.:
> INSERT INTO foo VALUES ('bar')
>
> ...then it escapes this to:
> INSERT INTO foo VALUES (''bar'')[/color]

I don't think you're using it correctly...
"PQescapeSt ring escapes a string for use within an SQL commmand."
....
"The single quotes that must surround PostgreSQL string literals are not
included in the result string; they should be provided in the SQL
command that the result is inserted into."

The intent is not for PQescapeString to take a query string, but a
string for use within a query string (for example, the literal bar in the
above).


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Tom Lane]

Re: C API, PQconnectdb and options Q.

"D. Stimits" <stimits@comcas t.net> writes:[color=blue]
> What I am wonder is (a) how to
> use the tty= in the string passed to PQconnectdb, and (b) a reference
> URL for what options are available in the options= part of the string
> parameters accepted by PQconnectdb.[/color]

tty= is a dead option; it was disabled years ago on security grounds.
I'd suggest enabling query logging so you can see in the postmaster log
exactly what query string got sent by your application. The options=
string is included in the command line options for the "postgres"
backend process --- the useful part of this is
-c parametervariab le=value
which is pretty nearly equivalent to doing a SET parametervariab le=value
after connecting.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Tom Lane]

Re: C API, PQconnectdb and options Q.

"D. Stimits" <stimits@comcas t.net> writes:[color=blue]
> What I am wonder is (a) how to
> use the tty= in the string passed to PQconnectdb, and (b) a reference
> URL for what options are available in the options= part of the string
> parameters accepted by PQconnectdb.[/color]

tty= is a dead option; it was disabled years ago on security grounds.
I'd suggest enabling query logging so you can see in the postmaster log
exactly what query string got sent by your application. The options=
string is included in the command line options for the "postgres"
backend process --- the useful part of this is
-c parametervariab le=value
which is pretty nearly equivalent to doing a SET parametervariab le=value
after connecting.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org