Re: [HACKERS] dblink: add polymorphic functions.

On 03/11/2016 08:51 AM, Robert Haas wrote: > Thanks for understanding. Rejecting patches is not much more fun that > getting your patches rejected, but it's got to be done... sorry! +1 Sorry I didn't already do this myself when it became clear I wasn't going to get it done in time. -- Crunchy

Re: [HACKERS] dblink: add polymorphic functions.

On Fri, Mar 11, 2016 at 8:44 AM, Joe Conway wrote: > On 03/11/2016 08:31 AM, Robert Haas wrote: >> On Thu, Jan 28, 2016 at 6:12 AM, Alvaro Herrera >> wrote: >>> Joe Conway wrote: >>> Ok, back to the drawing board. Thanks for the feedback. >>> >>> Closing this one as returned-with-feedback.

Re: [HACKERS] dblink: add polymorphic functions.

On 03/11/2016 08:31 AM, Robert Haas wrote: > On Thu, Jan 28, 2016 at 6:12 AM, Alvaro Herrera > wrote: >> Joe Conway wrote: >> >>> Ok, back to the drawing board. Thanks for the feedback. >> >> Closing this one as returned-with-feedback. Please do resubmit for >> CF 2016-03. > > Joe, it looks like

Re: [HACKERS] dblink: add polymorphic functions.

On Thu, Jan 28, 2016 at 6:12 AM, Alvaro Herrera wrote: > Joe Conway wrote: > >> Ok, back to the drawing board. Thanks for the feedback. > > Closing this one as returned-with-feedback. Please do resubmit for > CF 2016-03. Joe, it looks like you reactivated this patch for CF 2016-03 even though it

Re: [HACKERS] dblink: add polymorphic functions.

Joe Conway wrote: > Ok, back to the drawing board. Thanks for the feedback. Closing this one as returned-with-feedback. Please do resubmit for CF 2016-03. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Se

Re: [HACKERS] dblink: add polymorphic functions.

On 01/08/2016 07:31 AM, Tom Lane wrote: > Alvaro Herrera writes: >> So, is this going anywhere? > > Oh, sorry, was I on the hook to review that? > > [ quick look... ] This doesn't seem like it responds to my criticism > above. I think what we want is that for every LookupTypeName call site > t

Re: [HACKERS] dblink: add polymorphic functions.

Alvaro Herrera writes: > Joe Conway wrote: >> On 07/30/2015 09:51 AM, Tom Lane wrote: >>> The main limitation of this patch is that it won't work for call sites >>> that pass pstate == NULL to LookupTypeName. There are a fair number >>> of them, some of which wouldn't care because they could neve

Re: [HACKERS] dblink: add polymorphic functions.

Joe Conway wrote: > On 07/30/2015 09:51 AM, Tom Lane wrote: > > Joe Conway writes: > >> What about just TYPE then? > > > >> SELECT x::TYPE(some_expression) FROM ... > >> SELECT CAST (x AS TYPE(some_expression)) FROM ... > > > The main limitation of this patch is that it won't work for ca

Re: [HACKERS] dblink: add polymorphic functions.

On 07/30/2015 09:51 AM, Tom Lane wrote: > Joe Conway writes: >> What about just TYPE then? > >> SELECT x::TYPE(some_expression) FROM ... >> SELECT CAST (x AS TYPE(some_expression)) FROM ... > The main limitation of this patch is that it won't work for call sites > that pass pstate == NUL

Re: [HACKERS] dblink: add polymorphic functions.

Alvaro Herrera writes: > Tom Lane wrote: >> Yeah, that would work. Quick-hack proof-of-concept patch attached. > This is a rather ugly, but I guess not untenable. I suppose we don't > care about any actual typmod, do we?. We get the type and typmod both from the expression. Example: regressi

Re: [HACKERS] dblink: add polymorphic functions.

Tom Lane wrote: > Joe Conway writes: > > What about just TYPE then? > > > SELECT x::TYPE(some_expression) FROM ... > > SELECT CAST (x AS TYPE(some_expression)) FROM ... > > Yeah, that would work. Quick-hack proof-of-concept patch attached. I'm amazed that this works without hacking the

Re: [HACKERS] dblink: add polymorphic functions.

Joe Conway writes: > What about just TYPE then? > SELECT x::TYPE(some_expression) FROM ... > SELECT CAST (x AS TYPE(some_expression)) FROM ... Yeah, that would work. Quick-hack proof-of-concept patch attached. Some usage examples in the regression database: regression=# select pg_typeo

Re: [HACKERS] dblink: add polymorphic functions.

On Thu, Jul 30, 2015 at 12:41 AM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/29/2015 07:58 PM, Tom Lane wrote: > > We can definitely do > > > > SELECT x::any_single_unreserved_word(some_expression) FROM ... > > > > because that's actually not something the gramm

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 07:58 PM, Tom Lane wrote: > We can definitely do > > SELECT x::any_single_unreserved_word(some_expression) FROM ... > > because that's actually not something the grammar needs to > distinguish from type-with-a-typmod; we can deal with t

Re: [HACKERS] dblink: add polymorphic functions.

Joe Conway writes: > On 07/29/2015 05:13 PM, Tom Lane wrote: >> What's possibly more palatable is to introduce some other special >> notation for "obtain the type of this expression at parse time". >> I'm thinking for example about >> >> SELECT x::pg_typeof(some_expression) FROM ... > You think

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 05:13 PM, Tom Lane wrote: > What's possibly more palatable is to introduce some other special > notation for "obtain the type of this expression at parse time". > I'm thinking for example about > > SELECT x::pg_typeof(some_expression) FR

Re: [HACKERS] dblink: add polymorphic functions.

I wrote: > Well, it would depend on how we fixed %TYPE, but my thought is that > we should teach the core parser to accept variable%TYPE anywhere that > a suitable "variable" is in scope. The core already allows related > syntaxes in some utility commands, but not within DML commands. I poked at

Re: [HACKERS] dblink: add polymorphic functions.

Merlin Moncure writes: > On Wed, Jul 29, 2015 at 12:53 PM, Joe Conway wrote: >> Ok, gotcha. So Tom's nearby comment about allowing the >> "p_rowtype%TYPE" syntax to be used in the CAST is spot on (as usual). >> In other words, to get a complete solution for you we would need to >> make both thing

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 12:53 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/29/2015 09:40 AM, Corey Huinker wrote: >> Say I've got a table my_partitioned_table (key1 integer, key2 >> integer, metric1 integer, metric2 integer); >> >> And I've got many partitions

Re: [HACKERS] dblink: add polymorphic functions.

> > Ok, gotcha. So Tom's nearby comment about allowing the > "p_rowtype%TYPE" syntax to be used in the CAST is spot on (as usual). > In other words, to get a complete solution for you we would need to > make both things work, so you could do this inside plpgsql: > > select * from cast(dblink(conn

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 09:40 AM, Corey Huinker wrote: > Say I've got a table my_partitioned_table (key1 integer, key2 > integer, metric1 integer, metric2 integer); > > And I've got many partitions on that table. My code lets you do > something like this: > >

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 12:14 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/29/2015 08:56 AM, Corey Huinker wrote: > > On Wed, Jul 29, 2015 at 10:48 AM, Tom Lane > sure why inserting a variable name is so much better than inserting > > a type name? > > > In a

Re: [HACKERS] dblink: add polymorphic functions.

Corey Huinker writes: > On Wed, Jul 29, 2015 at 10:48 AM, Tom Lane wrote: >> Not sure why inserting a variable name is so much better than inserting a >> type name? > In a polymorphic function, I don't know the return type. It's whatever type > was specified on the function call. > Say I've wri

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 08:56 AM, Corey Huinker wrote: > On Wed, Jul 29, 2015 at 10:48 AM, Tom Lane sure why inserting a variable name is so much better than inserting > a type name? > In a polymorphic function, I don't know the return type. It's > whatever ty

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 10:48 AM, Tom Lane wrote: > Corey Huinker writes: > > On Wed, Jul 29, 2015 at 3:48 AM, Heikki Linnakangas > wrote: > >> Let's pursue the "CAST(srf() AS row_rtype)" syntax that Joe suggested > >> upthread ( > >> http://www.postgresql.org/message-id/559a9643.9070...@joecon

Re: [HACKERS] dblink: add polymorphic functions.

Corey Huinker writes: > On Wed, Jul 29, 2015 at 3:48 AM, Heikki Linnakangas wrote: >> Let's pursue the "CAST(srf() AS row_rtype)" syntax that Joe suggested >> upthread ( >> http://www.postgresql.org/message-id/559a9643.9070...@joeconway.com). For >> some reason, the discussion went on around the

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 3:48 AM, Heikki Linnakangas wrote: > On 07/18/2015 01:32 AM, Corey Huinker wrote: > >> So this patch would result in less C code while still adding 3 new >> functions. Can anyone think of why that wouldn't be the best way to go? >> > > Let's pursue the "CAST(srf() AS row_r

Re: [HACKERS] dblink: add polymorphic functions.

On 07/18/2015 01:32 AM, Corey Huinker wrote: So this patch would result in less C code while still adding 3 new functions. Can anyone think of why that wouldn't be the best way to go? Let's pursue the "CAST(srf() AS row_rtype)" syntax that Joe suggested upthread (http://www.postgresql.org/mes

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 12:21 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/08/2015 08:51 AM, Corey Huinker wrote: > > Questions: Would moving rowtype to the first parameter resolve the > > parameter ambiguity issue? > > Not for the existing functions but with n

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2015 08:51 AM, Corey Huinker wrote: > Questions: Would moving rowtype to the first parameter resolve the > parameter ambiguity issue? Not for the existing functions but with new functions I don't think it matters. You would know to always ign

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 11:29 AM, Merlin Moncure wrote: > On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 07/07/2015 10:22 PM, Michael Paquier wrote: > >> On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway > >> wrote: > >>> That explai

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/07/2015 10:22 PM, Michael Paquier wrote: >> On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway >> wrote: >>> That explains why the first example works while the second does >>> not. I'm not sur

Re: [HACKERS] dblink: add polymorphic functions.

2015-07-08 17:12 GMT+02:00 Joe Conway : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/07/2015 10:22 PM, Michael Paquier wrote: > > On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway > > wrote: > >> That explains why the first example works while the second does > >> not. I'm not sure how h

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2015 10:22 PM, Michael Paquier wrote: > On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway > wrote: >> That explains why the first example works while the second does >> not. I'm not sure how hard it would be to fix that, but it >> appears that that

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway wrote: > That explains why the first example works while the second does not. > I'm not sure how hard it would be to fix that, but it appears that > that is where we should focus. Wouldn't it be fine if we drop some of the functions proposed without imp

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 3:52 PM, Merlin Moncure wrote: > On Mon, Jul 6, 2015 at 11:13 AM, Corey Huinker > wrote: > > On Mon, Jul 6, 2015 at 11:33 AM, Merlin Moncure > wrote: > >> > >> On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway wrote: > >> > -BEGIN PGP SIGNED MESSAGE- > >> > Hash: SHA1 >

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 11:13 AM, Corey Huinker wrote: > On Mon, Jul 6, 2015 at 11:33 AM, Merlin Moncure wrote: >> >> On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > On 07/06/2015 07:37 AM, Merlin Moncure wrote: >> >> yup, and at

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 11:33 AM, Merlin Moncure wrote: > On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 07/06/2015 07:37 AM, Merlin Moncure wrote: > >> yup, and at least one case now fails where previously it ran > >> through: p

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/06/2015 07:37 AM, Merlin Moncure wrote: >> yup, and at least one case now fails where previously it ran >> through: postgres=# select * from dblink('a', 'b', 'c'); ERROR: >> function dblin

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 07:37 AM, Merlin Moncure wrote: > yup, and at least one case now fails where previously it ran > through: postgres=# select * from dblink('a', 'b', 'c'); ERROR: > function dblink(unknown, unknown, unknown) is not unique Hmm, that is an i

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 10:08 AM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/06/2015 12:39 AM, Michael Paquier wrote: > >> Yeah, particularly the use of first_optarg makes things harder > >> to follow in the code with this patch. A C wrapper has the > >> disadvan

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 9:35 AM, Tom Lane wrote: > Joe Conway writes: >> Actually, I had in mind something like: >> 8<- >> inti; >> intnumargs; >> int *argtypes; > >> numargs = PG_NARGS(); >> argtypes = palloc(numargs * sizeof(int)); >> for (i = 0; i < numargs; i++) >

Re: [HACKERS] dblink: add polymorphic functions.

Joe Conway writes: > Actually, I had in mind something like: > 8<- > inti; > intnumargs; > int *argtypes; > numargs = PG_NARGS(); > argtypes = palloc(numargs * sizeof(int)); > for (i = 0; i < numargs; i++) > argtypes[i] = get_fn_expr_argtype(fcinfo->flinfo, i);

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 12:39 AM, Michael Paquier wrote: >> Yeah, particularly the use of first_optarg makes things harder >> to follow in the code with this patch. A C wrapper has the >> disadvantage to decentralize the argument checks to many places >> making

Re: [HACKERS] dblink: add polymorphic functions.

On Thu, Feb 19, 2015 at 4:06 PM, Corey Huinker wrote: > In the course of writing a small side project which hopefully will make its > way onto pgxn soon, I was writing functions that had a polymorphic result > set. > > create function foo( p_row_type anyelement, p_param1 ...) returns setof > anyel

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 4:23 PM, Michael Paquier wrote: > On Mon, Jul 6, 2015 at 10:00 AM, Joe Conway wrote: >> I wonder if it isn't better to just loop through all the args with >> get_fn_expr_argtype() every time and then test for the exact signature >> match? Another alternative might be to cre

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 10:00 AM, Joe Conway wrote: > I wonder if it isn't better to just loop through all the args with > get_fn_expr_argtype() every time and then test for the exact signature > match? Another alternative might be to create a wrapper C function for > each variant SQL function, but

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 4:25 AM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/22/2015 10:26 PM, Corey Huinker wrote: >> Changes in this patch: - added polymorphic versions of >> dblink_fetch() - upped dblink version # to 1.2 because of new >> functions - migration 1

Re: [HACKERS] dblink: add polymorphic functions.

On Sun, Jul 5, 2015 at 9:00 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/05/2015 12:25 PM, Joe Conway wrote: > > On 02/22/2015 10:26 PM, Corey Huinker wrote: > >> Changes in this patch: - added polymorphic versions of > >> dblink_fetch() - upped dblink version

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/05/2015 12:25 PM, Joe Conway wrote: > On 02/22/2015 10:26 PM, Corey Huinker wrote: >> Changes in this patch: - added polymorphic versions of >> dblink_fetch() - upped dblink version # to 1.2 because of new >> functions - migration 1.1 -> 1.2 -

Re: [HACKERS] dblink: add polymorphic functions - review

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2015 09:57 PM, Pavel Stehule wrote: > 2015-06-19 6:32 GMT+02:00 Thomas Munro > >: > > On Fri, Jun 19, 2015 at 4:17 PM, Pavel Stehule > mailto:pavel.steh...@gmail.com>> wrote: >> I am sorry. I didn't the

Re: [HACKERS] dblink: add polymorphic functions.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 10:26 PM, Corey Huinker wrote: > Changes in this patch: - added polymorphic versions of > dblink_fetch() - upped dblink version # to 1.2 because of new > functions - migration 1.1 -> 1.2 - DocBook changes for dblink(), > dblink_get_result

Re: [HACKERS] dblink: add polymorphic functions - review

2015-06-19 6:32 GMT+02:00 Thomas Munro : > On Fri, Jun 19, 2015 at 4:17 PM, Pavel Stehule > wrote: > > I am sorry. I didn't the original mail in my mailbox. > > There is a (rather well hidden) way to ask Majordomo to send you a > message that arrived before you subscribed, so that you can reply >

Re: [HACKERS] dblink: add polymorphic functions - review

On Fri, Jun 19, 2015 at 4:17 PM, Pavel Stehule wrote: > I am sorry. I didn't the original mail in my mailbox. There is a (rather well hidden) way to ask Majordomo to send you a message that arrived before you subscribed, so that you can reply without creating a new thread. I think you have to su

Re: [HACKERS] dblink: add polymorphic functions - review

2015-06-19 2:17 GMT+02:00 Michael Paquier : > On Thu, Jun 18, 2015 at 10:44 PM, Pavel Stehule > wrote: > > Hi > > > > I am trying to check your patch - but diffs that you sent to mailing list > > are inconsistent. > > > > Please, can you send one complete patch? > > In order to follow more easily

Re: [HACKERS] dblink: add polymorphic functions - review

On Thu, Jun 18, 2015 at 10:44 PM, Pavel Stehule wrote: > Hi > > I am trying to check your patch - but diffs that you sent to mailing list > are inconsistent. > > Please, can you send one complete patch? In order to follow more easily the thread of this patch, could you answer directly to the exis

[HACKERS] dblink: add polymorphic functions - review

Hi I am trying to check your patch - but diffs that you sent to mailing list are inconsistent. Please, can you send one complete patch? Regards Pavel

Re: [HACKERS] dblink: add polymorphic functions.

Changes in this patch: - added polymorphic versions of dblink_fetch() - upped dblink version # to 1.2 because of new functions - migration 1.1 -> 1.2 - DocBook changes for dblink(), dblink_get_result(), dblink_fetch() On Sun, Feb 22, 2015 at 11:38 PM, Corey Huinker wrote: > "nevermind". Found it

Re: [HACKERS] dblink: add polymorphic functions.

"nevermind". Found it. On Sun, Feb 22, 2015 at 11:18 PM, Corey Huinker wrote: > Yes, that was it, I discovered it myself and should have posted a > "nevermind". > > Now I'm slogging through figuring out where to find elog() messages from > the temporary server. It's slow, but it's progress. > >

Re: [HACKERS] dblink: add polymorphic functions.

Yes, that was it, I discovered it myself and should have posted a "nevermind". Now I'm slogging through figuring out where to find elog() messages from the temporary server. It's slow, but it's progress. On Sun, Feb 22, 2015 at 10:39 PM, Michael Paquier wrote: > On Mon, Feb 23, 2015 at 12:03 PM

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Feb 23, 2015 at 12:03 PM, Corey Huinker wrote: > + ERROR: could not stat file > "/home/ubuntu/src/postgres/contrib/dblink/tmp_check/install/usr/local/pgsql/share/extension/dblink--1.2.sql": > No such file or directory Didn't you forget to add dblink--1.2.sql to DATA in contrib/dblink Mak

Re: [HACKERS] dblink: add polymorphic functions.

I seem to be getting tripped up in the regression test. This line was found in regression.diff + ERROR: could not stat file "/home/ubuntu/src/postgres/contrib/dblink/tmp_check/install/usr/local/pgsql/share/extension/dblink--1.2.sql": No such file or directory The file dblink--1.2.sql does exist

Re: [HACKERS] dblink: add polymorphic functions.

On Fri, Feb 20, 2015 at 2:50 PM, Corey Huinker wrote: > Thanks - completely new to this process, so I'm going to need > walking-through of it. I promise to document what I learn and try to add > that to the commitfest wiki. Where can I go for guidance about documentation > format and regression te

Re: [HACKERS] dblink: add polymorphic functions.

Thanks - completely new to this process, so I'm going to need walking-through of it. I promise to document what I learn and try to add that to the commitfest wiki. Where can I go for guidance about documentation format and regression tests? Author field is presently being finicky, reported that to

Re: [HACKERS] dblink: add polymorphic functions.

On Fri, Feb 20, 2015 at 7:06 AM, Corey Huinker wrote: > Proposed patch attached. At quick glance, this patch lacks two things: - regression test coverage - documentation (Note: do not forget to add your name in the field "Author" when adding a new patch in the CF app). -- Michael -- Sent via

[HACKERS] dblink: add polymorphic functions.

In the course of writing a small side project which hopefully will make its way onto pgxn soon, I was writing functions that had a polymorphic result set. create function foo( p_row_type anyelement, p_param1 ...) returns setof anyelement Inside that function would be multiple calls to dblink() in