pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedPQfformat() and Composite Formatted Results
9+ messages / 3 participants
[nested] [flat]
* PQfformat() and Composite Formatted Results
@ 2005-12-30 23:37 Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 9+ messages in thread
From: Volkan YAZICI @ 2005-12-30 23:37 UTC (permalink / raw)
To: pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
@ 2005-12-30 23:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Re: PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
0 siblings, 1 reply; 9+ messages in thread
From: Tom Lane @ 2005-12-30 23:52 UTC (permalink / raw)
To: Volkan YAZICI <yazicivo@ttnet.net.tr>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-01-08 20:34 ` Volkan YAZICI <yazicivo@ttnet.net.tr>
2006-02-03 18:55 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-04 00:35 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 9+ messages in thread
From: Volkan YAZICI @ 2006-01-08 20:34 UTC (permalink / raw)
To: pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Re: PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
@ 2006-02-03 18:55 ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-03 21:12 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 9+ messages in thread
From: Bruce Momjian @ 2006-02-03 18:55 UTC (permalink / raw)
To: Volkan YAZICI <yazicivo@ttnet.net.tr>; +Cc: pgsql-interfaces
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, Pennsylvania 19073
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Re: PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2006-02-03 18:55 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
@ 2006-02-03 21:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-04 00:35 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 9+ messages in thread
From: Tom Lane @ 2006-02-03 21:12 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Volkan YAZICI <yazicivo@ttnet.net.tr>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Re: PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2006-02-03 18:55 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-03 21:12 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-02-04 00:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-04 02:25 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 9+ messages in thread
From: Bruce Momjian @ 2006-02-04 00:35 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Volkan YAZICI <yazicivo@ttnet.net.tr>; pgsql-interfaces
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, Pennsylvania 19073
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Re: PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2006-02-03 18:55 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-03 21:12 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-02-04 00:35 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
@ 2006-02-04 02:25 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-04 02:33 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 9+ messages in thread
From: Tom Lane @ 2006-02-04 02:25 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Volkan YAZICI <yazicivo@ttnet.net.tr>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Re: PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2006-02-03 18:55 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-03 21:12 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-02-04 00:35 ` Re: PQfformat() and Composite Formatted Results Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-04 02:25 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-02-04 02:33 ` Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 9+ messages in thread
From: Bruce Momjian @ 2006-02-04 02:33 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Volkan YAZICI <yazicivo@ttnet.net.tr>; pgsql-interfaces
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, Pennsylvania 19073
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: PQfformat() and Composite Formatted Results
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Re: PQfformat() and Composite Formatted Results Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Re: PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
@ 2006-02-04 00:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 0 replies; 9+ messages in thread
From: Bruce Momjian @ 2006-02-04 00:35 UTC (permalink / raw)
To: Volkan YAZICI <yazicivo@ttnet.net.tr>; +Cc: pgsql-interfaces
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, Pennsylvania 19073
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2006-02-04 02:33 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-12-30 23:37 PQfformat() and Composite Formatted Results Volkan YAZICI <yazicivo@ttnet.net.tr>
2005-12-30 23:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-01-08 20:34 ` Volkan YAZICI <yazicivo@ttnet.net.tr>
2006-02-03 18:55 ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-03 21:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-04 00:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-04 02:25 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-04 02:33 ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-04 00:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox