PostgreSQL: relationship between types given w/placeholders and types in PQexecPrepared() paramValues...












1















If I have a placeholder given as $1::text, does that means the corresponding paramValues that I pass to PQexecPrepared() needs to be a C-style string? So far I've done it that way and so far it's worked. (And so far, I've needed to give ::text along w/the placeholder or I get an error). But what if I declare the placeholder as $1:int? Can I still give a C-style string in the paramValues? Should I give a C-style string? The docs on this are a bit vague and aren't very clear on what to do w/the paramTypes parameter of PQprepare() which I've left NULL anyway, so far.



More importantly, what if I need to express an array, like as $1::text? The docs say nothing of this and the solutions I've seen so far don't seem very efficient or even very reliable, such as https://stackoverflow.com/a/36930781/1676382. So far I've been giving the values to PQexecPrepared() in "text" format, but should I be switching to "binary" and in what conditions?



So far I've been able to get away w/some pretty simple queries:



const char *query = "SELECT * FROM table WHERE col=$1::text";
const void *types = NULL; //Wish I knew what could be assigned to an Oid
PQprepare(conn, name, query, 1, static_cast<const Oid *>(types));


...



const int *lengths = NULL;      //It doesn't seem like these vars are used for anything right now
const int *formats = NULL;
int result_format = 0;
//values is a const char * const * and is the return value of QScopedArrayPointer <char*>::data()
res = PQexecPrepared(conn, name, 1, values, lengths, formats, result_format);


Now so far this works, but what if I wanted to have



WHERE col = ANY ($1::text)


? How would I express values that is passed to PQexecPrepared()?



My project is in GNU C++ using PostgreSQL 9.6.










share|improve this question

























  • That depends: Are you sending the parameters in text or binary format? Do you specify their types or not? Maybe it would help if you add a code sample to the question.

    – Laurenz Albe
    Jan 18 at 15:53











  • @LaurenzAlbe The question shows I'm specifying types. So far I'm doing it in "text" format, but another part of the question is that I don't know if I should be doing "binary" and in what conditions. I'll work on code snippets.

    – Opux
    Jan 18 at 15:57













  • Sorry, I should have been more specific: how do the paramTypes and paramFormats arguments to PQexecParams look?

    – Laurenz Albe
    Jan 18 at 16:04











  • @LaurenzAlbe I've included snippets explaining what I'm doing and what I want to do (but the short answer is that those parameters are NULL)

    – Opux
    Jan 18 at 16:14


















1















If I have a placeholder given as $1::text, does that means the corresponding paramValues that I pass to PQexecPrepared() needs to be a C-style string? So far I've done it that way and so far it's worked. (And so far, I've needed to give ::text along w/the placeholder or I get an error). But what if I declare the placeholder as $1:int? Can I still give a C-style string in the paramValues? Should I give a C-style string? The docs on this are a bit vague and aren't very clear on what to do w/the paramTypes parameter of PQprepare() which I've left NULL anyway, so far.



More importantly, what if I need to express an array, like as $1::text? The docs say nothing of this and the solutions I've seen so far don't seem very efficient or even very reliable, such as https://stackoverflow.com/a/36930781/1676382. So far I've been giving the values to PQexecPrepared() in "text" format, but should I be switching to "binary" and in what conditions?



So far I've been able to get away w/some pretty simple queries:



const char *query = "SELECT * FROM table WHERE col=$1::text";
const void *types = NULL; //Wish I knew what could be assigned to an Oid
PQprepare(conn, name, query, 1, static_cast<const Oid *>(types));


...



const int *lengths = NULL;      //It doesn't seem like these vars are used for anything right now
const int *formats = NULL;
int result_format = 0;
//values is a const char * const * and is the return value of QScopedArrayPointer <char*>::data()
res = PQexecPrepared(conn, name, 1, values, lengths, formats, result_format);


Now so far this works, but what if I wanted to have



WHERE col = ANY ($1::text)


? How would I express values that is passed to PQexecPrepared()?



My project is in GNU C++ using PostgreSQL 9.6.










share|improve this question

























  • That depends: Are you sending the parameters in text or binary format? Do you specify their types or not? Maybe it would help if you add a code sample to the question.

    – Laurenz Albe
    Jan 18 at 15:53











  • @LaurenzAlbe The question shows I'm specifying types. So far I'm doing it in "text" format, but another part of the question is that I don't know if I should be doing "binary" and in what conditions. I'll work on code snippets.

    – Opux
    Jan 18 at 15:57













  • Sorry, I should have been more specific: how do the paramTypes and paramFormats arguments to PQexecParams look?

    – Laurenz Albe
    Jan 18 at 16:04











  • @LaurenzAlbe I've included snippets explaining what I'm doing and what I want to do (but the short answer is that those parameters are NULL)

    – Opux
    Jan 18 at 16:14
















1












1








1


0






If I have a placeholder given as $1::text, does that means the corresponding paramValues that I pass to PQexecPrepared() needs to be a C-style string? So far I've done it that way and so far it's worked. (And so far, I've needed to give ::text along w/the placeholder or I get an error). But what if I declare the placeholder as $1:int? Can I still give a C-style string in the paramValues? Should I give a C-style string? The docs on this are a bit vague and aren't very clear on what to do w/the paramTypes parameter of PQprepare() which I've left NULL anyway, so far.



More importantly, what if I need to express an array, like as $1::text? The docs say nothing of this and the solutions I've seen so far don't seem very efficient or even very reliable, such as https://stackoverflow.com/a/36930781/1676382. So far I've been giving the values to PQexecPrepared() in "text" format, but should I be switching to "binary" and in what conditions?



So far I've been able to get away w/some pretty simple queries:



const char *query = "SELECT * FROM table WHERE col=$1::text";
const void *types = NULL; //Wish I knew what could be assigned to an Oid
PQprepare(conn, name, query, 1, static_cast<const Oid *>(types));


...



const int *lengths = NULL;      //It doesn't seem like these vars are used for anything right now
const int *formats = NULL;
int result_format = 0;
//values is a const char * const * and is the return value of QScopedArrayPointer <char*>::data()
res = PQexecPrepared(conn, name, 1, values, lengths, formats, result_format);


Now so far this works, but what if I wanted to have



WHERE col = ANY ($1::text)


? How would I express values that is passed to PQexecPrepared()?



My project is in GNU C++ using PostgreSQL 9.6.










share|improve this question
















If I have a placeholder given as $1::text, does that means the corresponding paramValues that I pass to PQexecPrepared() needs to be a C-style string? So far I've done it that way and so far it's worked. (And so far, I've needed to give ::text along w/the placeholder or I get an error). But what if I declare the placeholder as $1:int? Can I still give a C-style string in the paramValues? Should I give a C-style string? The docs on this are a bit vague and aren't very clear on what to do w/the paramTypes parameter of PQprepare() which I've left NULL anyway, so far.



More importantly, what if I need to express an array, like as $1::text? The docs say nothing of this and the solutions I've seen so far don't seem very efficient or even very reliable, such as https://stackoverflow.com/a/36930781/1676382. So far I've been giving the values to PQexecPrepared() in "text" format, but should I be switching to "binary" and in what conditions?



So far I've been able to get away w/some pretty simple queries:



const char *query = "SELECT * FROM table WHERE col=$1::text";
const void *types = NULL; //Wish I knew what could be assigned to an Oid
PQprepare(conn, name, query, 1, static_cast<const Oid *>(types));


...



const int *lengths = NULL;      //It doesn't seem like these vars are used for anything right now
const int *formats = NULL;
int result_format = 0;
//values is a const char * const * and is the return value of QScopedArrayPointer <char*>::data()
res = PQexecPrepared(conn, name, 1, values, lengths, formats, result_format);


Now so far this works, but what if I wanted to have



WHERE col = ANY ($1::text)


? How would I express values that is passed to PQexecPrepared()?



My project is in GNU C++ using PostgreSQL 9.6.







c postgresql prepared-statement type-resolution






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 18 at 16:56









Laurenz Albe

45.4k102748




45.4k102748










asked Jan 18 at 15:04









OpuxOpux

426619




426619













  • That depends: Are you sending the parameters in text or binary format? Do you specify their types or not? Maybe it would help if you add a code sample to the question.

    – Laurenz Albe
    Jan 18 at 15:53











  • @LaurenzAlbe The question shows I'm specifying types. So far I'm doing it in "text" format, but another part of the question is that I don't know if I should be doing "binary" and in what conditions. I'll work on code snippets.

    – Opux
    Jan 18 at 15:57













  • Sorry, I should have been more specific: how do the paramTypes and paramFormats arguments to PQexecParams look?

    – Laurenz Albe
    Jan 18 at 16:04











  • @LaurenzAlbe I've included snippets explaining what I'm doing and what I want to do (but the short answer is that those parameters are NULL)

    – Opux
    Jan 18 at 16:14





















  • That depends: Are you sending the parameters in text or binary format? Do you specify their types or not? Maybe it would help if you add a code sample to the question.

    – Laurenz Albe
    Jan 18 at 15:53











  • @LaurenzAlbe The question shows I'm specifying types. So far I'm doing it in "text" format, but another part of the question is that I don't know if I should be doing "binary" and in what conditions. I'll work on code snippets.

    – Opux
    Jan 18 at 15:57













  • Sorry, I should have been more specific: how do the paramTypes and paramFormats arguments to PQexecParams look?

    – Laurenz Albe
    Jan 18 at 16:04











  • @LaurenzAlbe I've included snippets explaining what I'm doing and what I want to do (but the short answer is that those parameters are NULL)

    – Opux
    Jan 18 at 16:14



















That depends: Are you sending the parameters in text or binary format? Do you specify their types or not? Maybe it would help if you add a code sample to the question.

– Laurenz Albe
Jan 18 at 15:53





That depends: Are you sending the parameters in text or binary format? Do you specify their types or not? Maybe it would help if you add a code sample to the question.

– Laurenz Albe
Jan 18 at 15:53













@LaurenzAlbe The question shows I'm specifying types. So far I'm doing it in "text" format, but another part of the question is that I don't know if I should be doing "binary" and in what conditions. I'll work on code snippets.

– Opux
Jan 18 at 15:57







@LaurenzAlbe The question shows I'm specifying types. So far I'm doing it in "text" format, but another part of the question is that I don't know if I should be doing "binary" and in what conditions. I'll work on code snippets.

– Opux
Jan 18 at 15:57















Sorry, I should have been more specific: how do the paramTypes and paramFormats arguments to PQexecParams look?

– Laurenz Albe
Jan 18 at 16:04





Sorry, I should have been more specific: how do the paramTypes and paramFormats arguments to PQexecParams look?

– Laurenz Albe
Jan 18 at 16:04













@LaurenzAlbe I've included snippets explaining what I'm doing and what I want to do (but the short answer is that those parameters are NULL)

– Opux
Jan 18 at 16:14







@LaurenzAlbe I've included snippets explaining what I'm doing and what I want to do (but the short answer is that those parameters are NULL)

– Opux
Jan 18 at 16:14














1 Answer
1






active

oldest

votes


















0














If you sent untyped string arguments like in your example, they will have type unknown and converted to the proper type, if possible. This is quite similar to string literals in SQL statements.



It should not be necessary to cast to text in the SQL statement. I'd be curious what the type of col is if you find that cast necessary.



If you want to pass a text in text format, simply use its string representation, for example



{first element,two,three}


This will also work for integers and other types; just use the text representation of the value.



You can also use the paramTypes argument to PQexecParams to specify which type it is explicitly. The possible values are in the oid column of pg_type, and they are constant for system types.






share|improve this answer


























  • I could have sworn that the ::text was essential, but I can't duplicate the error that I got before. In any case, is this any better than stackoverflow.com/a/36930781/1676382? It seems the engine still has to parse a string and then there's the danger of what happens if the delimiter character appears in one of the values

    – Opux
    Jan 18 at 19:25











  • Then you have to escape the entry with double quotes, and double quotes inside the entry with backslashes: {entry one,entry two,"evil{,}"entry"}

    – Laurenz Albe
    yesterday













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54256611%2fpostgresql-relationship-between-types-given-w-placeholders-and-types-in-pqexecp%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














If you sent untyped string arguments like in your example, they will have type unknown and converted to the proper type, if possible. This is quite similar to string literals in SQL statements.



It should not be necessary to cast to text in the SQL statement. I'd be curious what the type of col is if you find that cast necessary.



If you want to pass a text in text format, simply use its string representation, for example



{first element,two,three}


This will also work for integers and other types; just use the text representation of the value.



You can also use the paramTypes argument to PQexecParams to specify which type it is explicitly. The possible values are in the oid column of pg_type, and they are constant for system types.






share|improve this answer


























  • I could have sworn that the ::text was essential, but I can't duplicate the error that I got before. In any case, is this any better than stackoverflow.com/a/36930781/1676382? It seems the engine still has to parse a string and then there's the danger of what happens if the delimiter character appears in one of the values

    – Opux
    Jan 18 at 19:25











  • Then you have to escape the entry with double quotes, and double quotes inside the entry with backslashes: {entry one,entry two,"evil{,}"entry"}

    – Laurenz Albe
    yesterday


















0














If you sent untyped string arguments like in your example, they will have type unknown and converted to the proper type, if possible. This is quite similar to string literals in SQL statements.



It should not be necessary to cast to text in the SQL statement. I'd be curious what the type of col is if you find that cast necessary.



If you want to pass a text in text format, simply use its string representation, for example



{first element,two,three}


This will also work for integers and other types; just use the text representation of the value.



You can also use the paramTypes argument to PQexecParams to specify which type it is explicitly. The possible values are in the oid column of pg_type, and they are constant for system types.






share|improve this answer


























  • I could have sworn that the ::text was essential, but I can't duplicate the error that I got before. In any case, is this any better than stackoverflow.com/a/36930781/1676382? It seems the engine still has to parse a string and then there's the danger of what happens if the delimiter character appears in one of the values

    – Opux
    Jan 18 at 19:25











  • Then you have to escape the entry with double quotes, and double quotes inside the entry with backslashes: {entry one,entry two,"evil{,}"entry"}

    – Laurenz Albe
    yesterday
















0












0








0







If you sent untyped string arguments like in your example, they will have type unknown and converted to the proper type, if possible. This is quite similar to string literals in SQL statements.



It should not be necessary to cast to text in the SQL statement. I'd be curious what the type of col is if you find that cast necessary.



If you want to pass a text in text format, simply use its string representation, for example



{first element,two,three}


This will also work for integers and other types; just use the text representation of the value.



You can also use the paramTypes argument to PQexecParams to specify which type it is explicitly. The possible values are in the oid column of pg_type, and they are constant for system types.






share|improve this answer















If you sent untyped string arguments like in your example, they will have type unknown and converted to the proper type, if possible. This is quite similar to string literals in SQL statements.



It should not be necessary to cast to text in the SQL statement. I'd be curious what the type of col is if you find that cast necessary.



If you want to pass a text in text format, simply use its string representation, for example



{first element,two,three}


This will also work for integers and other types; just use the text representation of the value.



You can also use the paramTypes argument to PQexecParams to specify which type it is explicitly. The possible values are in the oid column of pg_type, and they are constant for system types.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 18 at 17:00

























answered Jan 18 at 16:54









Laurenz AlbeLaurenz Albe

45.4k102748




45.4k102748













  • I could have sworn that the ::text was essential, but I can't duplicate the error that I got before. In any case, is this any better than stackoverflow.com/a/36930781/1676382? It seems the engine still has to parse a string and then there's the danger of what happens if the delimiter character appears in one of the values

    – Opux
    Jan 18 at 19:25











  • Then you have to escape the entry with double quotes, and double quotes inside the entry with backslashes: {entry one,entry two,"evil{,}"entry"}

    – Laurenz Albe
    yesterday





















  • I could have sworn that the ::text was essential, but I can't duplicate the error that I got before. In any case, is this any better than stackoverflow.com/a/36930781/1676382? It seems the engine still has to parse a string and then there's the danger of what happens if the delimiter character appears in one of the values

    – Opux
    Jan 18 at 19:25











  • Then you have to escape the entry with double quotes, and double quotes inside the entry with backslashes: {entry one,entry two,"evil{,}"entry"}

    – Laurenz Albe
    yesterday



















I could have sworn that the ::text was essential, but I can't duplicate the error that I got before. In any case, is this any better than stackoverflow.com/a/36930781/1676382? It seems the engine still has to parse a string and then there's the danger of what happens if the delimiter character appears in one of the values

– Opux
Jan 18 at 19:25





I could have sworn that the ::text was essential, but I can't duplicate the error that I got before. In any case, is this any better than stackoverflow.com/a/36930781/1676382? It seems the engine still has to parse a string and then there's the danger of what happens if the delimiter character appears in one of the values

– Opux
Jan 18 at 19:25













Then you have to escape the entry with double quotes, and double quotes inside the entry with backslashes: {entry one,entry two,"evil{,}"entry"}

– Laurenz Albe
yesterday







Then you have to escape the entry with double quotes, and double quotes inside the entry with backslashes: {entry one,entry two,"evil{,}"entry"}

– Laurenz Albe
yesterday




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54256611%2fpostgresql-relationship-between-types-given-w-placeholders-and-types-in-pqexecp%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Callistus III

Ostreoida

Plistias Cous