Thread: PQfformat() and Composite Formatted Results
Hi, PQfformat() returns the format code indicating the format of the given column. But, AFAIC, it's not possible to gather composite formatted results using current query execution functions. They only permit to specify the return format of the whole result struct. (Like all of them will be binary or text.) Therefore, there doesn't remain any usage difference between PQbinaryTuples() and PQfformat(). Please fix me if I'm wrong. Is this remained as a TODO for the protocol or I missed something totally? Regards.
Volkan YAZICI <yazicivo@ttnet.net.tr> writes:
> PQfformat() returns the format code indicating the format of the
> given column. But, AFAIC, it's not possible to gather composite
> formatted results using current query execution functions. They
> only permit to specify the return format of the whole result
> struct. (Like all of them will be binary or text.) Therefore, there
> doesn't remain any usage difference between PQbinaryTuples() and
> PQfformat().
> Please fix me if I'm wrong. Is this remained as a TODO for the
> protocol or I missed something totally?
It's not a protocol restriction, it's a libpq restriction made in the
name of keeping the API from getting too unwieldy. We could add more
entry points with different parameter lists to address this. I have
a feeling that refactoring the API of the query functions entirely
might be a better idea, though.
regards, tom lane
Hi, I've prepared a patch[1] which makes it possible to use composite formats in query results. It defines PQexecParams() PQexecPrepared() PQsendQueryParams() PQsendPrepared() functions with last int resultFormat parameter replaced with int nResFormat, const int resParamFormats Therefore, it breaks compatibility with the existing PQ*Params() and PQ*Prepared() functions. (Use at your own risk.) There's also a test case[2] too [1] http://www.students.itu.edu.tr/~yazicivo/libpq_res_fmt.patch [2] http://www.students.itu.edu.tr/~yazicivo/pg_res_fmt.c Any comments will be appreciated. Regards. On Dec 30 06:52, Tom Lane wrote: > It's not a protocol restriction, it's a libpq restriction made in the > name of keeping the API from getting too unwieldy. We could add more > entry points with different parameter lists to address this. I have > a feeling that refactoring the API of the query functions entirely > might be a better idea, though.
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --------------------------------------------------------------------------- Volkan YAZICI wrote: > Hi, > > I've prepared a patch[1] which makes it possible to use composite formats > in query results. > > It defines > > PQexecParams() > PQexecPrepared() > PQsendQueryParams() > PQsendPrepared() > > functions with last > > int resultFormat > > parameter replaced with > > int nResFormat, > const int resParamFormats > > Therefore, it breaks compatibility with the existing PQ*Params() and > PQ*Prepared() functions. (Use at your own risk.) > > There's also a test case[2] too > > [1] http://www.students.itu.edu.tr/~yazicivo/libpq_res_fmt.patch > [2] http://www.students.itu.edu.tr/~yazicivo/pg_res_fmt.c > > > Any comments will be appreciated. > Regards. > > > On Dec 30 06:52, Tom Lane wrote: > > It's not a protocol restriction, it's a libpq restriction made in the > > name of keeping the API from getting too unwieldy. We could add more > > entry points with different parameter lists to address this. I have > > a feeling that refactoring the API of the query functions entirely > > might be a better idea, though. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Your patch has been added to the PostgreSQL unapplied patches list at: > http://momjian.postgresql.org/cgi-bin/pgpatches > It will be applied as soon as one of the PostgreSQL committers reviews > and approves it. There is 0 chance that this will be applied, because >> Therefore, it breaks compatibility with the existing PQ*Params() and >> PQ*Prepared() functions. (Use at your own risk.) regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > It will be applied as soon as one of the PostgreSQL committers reviews > > and approves it. > > There is 0 chance that this will be applied, because > > >> Therefore, it breaks compatibility with the existing PQ*Params() and > >> PQ*Prepared() functions. (Use at your own risk.) OK, patch removed, but you stated in email: > On Dec 30 06:52, Tom Lane wrote: > > It's not a protocol restriction, it's a libpq restriction made in the > > name of keeping the API from getting too unwieldy. We could add more > > entry points with different parameter lists to address this. I have > > a feeling that refactoring the API of the query functions entirely > > might be a better idea, though. so I thought you were saying that we need to just pick new function names or something. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Patch removed. --------------------------------------------------------------------------- Volkan YAZICI wrote: > Hi, > > I've prepared a patch[1] which makes it possible to use composite formats > in query results. > > It defines > > PQexecParams() > PQexecPrepared() > PQsendQueryParams() > PQsendPrepared() > > functions with last > > int resultFormat > > parameter replaced with > > int nResFormat, > const int resParamFormats > > Therefore, it breaks compatibility with the existing PQ*Params() and > PQ*Prepared() functions. (Use at your own risk.) > > There's also a test case[2] too > > [1] http://www.students.itu.edu.tr/~yazicivo/libpq_res_fmt.patch > [2] http://www.students.itu.edu.tr/~yazicivo/pg_res_fmt.c > > > Any comments will be appreciated. > Regards. > > > On Dec 30 06:52, Tom Lane wrote: > > It's not a protocol restriction, it's a libpq restriction made in the > > name of keeping the API from getting too unwieldy. We could add more > > entry points with different parameter lists to address this. I have > > a feeling that refactoring the API of the query functions entirely > > might be a better idea, though. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> There is 0 chance that this will be applied, because
>>
>>> Therefore, it breaks compatibility with the existing PQ*Params() and
>>> PQ*Prepared() functions. (Use at your own risk.)
> OK, patch removed, but you stated in email:
>> On Dec 30 06:52, Tom Lane wrote:
> It's not a protocol restriction, it's a libpq restriction made in the
> name of keeping the API from getting too unwieldy. We could add more
> entry points with different parameter lists to address this. I have
> a feeling that refactoring the API of the query functions entirely
> might be a better idea, though.
> so I thought you were saying that we need to just pick new function
> names or something.
I didn't say we couldn't do something involving new function names;
I said *this* patch isn't acceptable ...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> There is 0 chance that this will be applied, because > >> > >>> Therefore, it breaks compatibility with the existing PQ*Params() and > >>> PQ*Prepared() functions. (Use at your own risk.) > > > OK, patch removed, but you stated in email: > >> On Dec 30 06:52, Tom Lane wrote: > > It's not a protocol restriction, it's a libpq restriction made in the > > name of keeping the API from getting too unwieldy. We could add more > > entry points with different parameter lists to address this. I have > > a feeling that refactoring the API of the query functions entirely > > might be a better idea, though. > > > so I thought you were saying that we need to just pick new function > > names or something. > > I didn't say we couldn't do something involving new function names; > I said *this* patch isn't acceptable ... OK, so does he rework it or do we? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073