Thread: PQfformat() and Composite Formatted Results

PQfformat() and Composite Formatted Results

From
Volkan YAZICI
Date:
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.


Re: PQfformat() and Composite Formatted Results

From
Tom Lane
Date:
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


Re: PQfformat() and Composite Formatted Results

From
Volkan YAZICI
Date:
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.


Re: PQfformat() and Composite Formatted Results

From
Bruce Momjian
Date:
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
 


Re: PQfformat() and Composite Formatted Results

From
Tom Lane
Date:
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


Re: PQfformat() and Composite Formatted Results

From
Bruce Momjian
Date:
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
 


Re: PQfformat() and Composite Formatted Results

From
Bruce Momjian
Date:
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
 


Re: PQfformat() and Composite Formatted Results

From
Tom Lane
Date:
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


Re: PQfformat() and Composite Formatted Results

From
Bruce Momjian
Date:
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