Re: [HACKERS] Getting the results columns before execution
Jan Wieck wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> Tom Lane wrote: > Are those exposed through the libpq interface? > >>> > >>> No, because libpq doesn't really have any concept of prepared statements. > >>> It would probably make sense to add some more API to libpq to allow > >>> creation and interrogation of prepared statements, but no one's got > >>> around to that yet. > > > >> Uh, if libpq doesn't know about it, how is that information accessed? > > > > That's exactly the problem... > > Currently the only way to do that would be to have a user defined > function that calls SPI_prepare() with the query string and returns the > desired information to the client. > Oh, I understand now. Added to TODO: * Allow libpq to return information about prepared queries -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Getting the results columns before execution
Jan Wieck wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> Tom Lane wrote: > Are those exposed through the libpq interface? > >>> > >>> No, because libpq doesn't really have any concept of prepared statements. > >>> It would probably make sense to add some more API to libpq to allow > >>> creation and interrogation of prepared statements, but no one's got > >>> around to that yet. > > > >> Uh, if libpq doesn't know about it, how is that information accessed? > > > > That's exactly the problem... > > Currently the only way to do that would be to have a user defined > function that calls SPI_prepare() with the query string and returns the > desired information to the client. It was my understanding that the new protocol passes this information to the cilent, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Getting the results columns before execution
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: Tom Lane wrote: Are those exposed through the libpq interface? No, because libpq doesn't really have any concept of prepared statements. It would probably make sense to add some more API to libpq to allow creation and interrogation of prepared statements, but no one's got around to that yet. Uh, if libpq doesn't know about it, how is that information accessed? That's exactly the problem... Currently the only way to do that would be to have a user defined function that calls SPI_prepare() with the query string and returns the desired information to the client. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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
Re: [HACKERS] Getting the results columns before execution
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >>> Are those exposed through the libpq interface? >> >> No, because libpq doesn't really have any concept of prepared statements. >> It would probably make sense to add some more API to libpq to allow >> creation and interrogation of prepared statements, but no one's got >> around to that yet. > Uh, if libpq doesn't know about it, how is that information accessed? That's exactly the problem... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Getting the results columns before execution
Tom Lane wrote: > Shachar Shemesh <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Sure it is, if you are using the V3 protocol (new in 7.4). > >> See the Describe message types. > > > Are those exposed through the libpq interface? > > No, because libpq doesn't really have any concept of prepared statements. > It would probably make sense to add some more API to libpq to allow > creation and interrogation of prepared statements, but no one's got > around to that yet. Uh, if libpq doesn't know about it, how is that information accessed? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Getting the results columns before execution
Shachar Shemesh <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Sure it is, if you are using the V3 protocol (new in 7.4). >> See the Describe message types. > Are those exposed through the libpq interface? No, because libpq doesn't really have any concept of prepared statements. It would probably make sense to add some more API to libpq to allow creation and interrogation of prepared statements, but no one's got around to that yet. regards, tom lane ---(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
Re: [HACKERS] Getting the results columns before execution
Tom Lane wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: ... This is a problem, as merely preparing a command is not enough to get the returned rows information. Sure it is, if you are using the V3 protocol (new in 7.4). See the Describe message types. regards, tom lane Are those exposed through the libpq interface? If not, is there a way to use the libpq interface for most operations, and only for the rest to use whatever it is you are suggesting I use (couldn't locate it in the docs, yet) Funnily enough, mandating protocol version 3 is not my problem at the moment. I may have to do so for a host of other reasons as well. I guess, if you want to use an earlier version of the database, you will have to make do with the ole db to ODBC interface. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Getting the results columns before execution
Shachar Shemesh <[EMAIL PROTECTED]> writes: > ... This is a problem, as merely preparing a command is > not enough to get the returned rows information. Sure it is, if you are using the V3 protocol (new in 7.4). See the Describe message types. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Getting the results columns before execution
On Monday 19 January 2004 15:13, Shachar Shemesh wrote: > Hi all, > > From the OLE DB manual: > > The consumer can also get information about the columns of the rowset > > by calling IColumnsInfo::GetColumnInfo, which all providers must > > support, or IColumnsRowset::GetColumnsRowset, which providers may > > support, on the command. > > > > Before calling GetColumnInfo or GetColumnsRowset, the consumer must > > set the command text and, if the provider supports command > > preparation, prepare the command object. > > The problem - it appears there is no requirement to execute the command > before asking about the rowset returned. Only setting the actual command > and preparing it. This is a problem, as merely preparing a command is > not enough to get the returned rows information. > > I'm wondering whether anyone on this list(s) have an idea how to solve > this? I can start the command in a cursor, and not retrieve information > until requested. I can also execute the command with "where 0" appended > to it. Neither solutions seem very practical or good performance wise. > > Shachar LIMIT 0 will do ? I do it often when I need to know structure of the result without returning any rows. Regards ! ---(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
[HACKERS] Getting the results columns before execution
Hi all, From the OLE DB manual: The consumer can also get information about the columns of the rowset by calling IColumnsInfo::GetColumnInfo, which all providers must support, or IColumnsRowset::GetColumnsRowset, which providers may support, on the command. Before calling GetColumnInfo or GetColumnsRowset, the consumer must set the command text and, if the provider supports command preparation, prepare the command object. The problem - it appears there is no requirement to execute the command before asking about the rowset returned. Only setting the actual command and preparing it. This is a problem, as merely preparing a command is not enough to get the returned rows information. I'm wondering whether anyone on this list(s) have an idea how to solve this? I can start the command in a cursor, and not retrieve information until requested. I can also execute the command with "where 0" appended to it. Neither solutions seem very practical or good performance wise. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
