Hi,
I'm trying to write some user-defined functions in C which operate on a
large object (so their common first argument will be an OID referencing an
object in the pg_largeobject catalog table created with lo_create()) and
return either a single row or a set depending on the function. Depending o
On Tue, Apr 2, 2013 at 10:55 AM, Tom Lane wrote:
> if you just write
>
> SELECT function_returning_record(...) FROM ...
>
> and not
>
> SELECT (function_returning_record(...)).* FROM ...
>
> I think that the run-time-blessed-record-type hack will work okay.
> Of course that greatl
Hi,
I have a UDF (written in C) that returns SETOF RECORD of an anonymous
record type
(defined via OUT parameters). I'm trying to use array_agg() to transform
its output to
an array:
pg_dev=# SELECT array_agg((my_setof_record_returning_func()).col1);
ERROR: set-valued function called in context
If an aggregate function cannot handle rows generated
in the columns-part of the statement, then why is a single-column row(s)
result acceptable in the first statement?
On Wed, Apr 24, 2013 at 1:29 PM, hubert depesz lubaczewski <
dep...@depesz.com> wrote:
> On Wed, Apr 24, 2013 at 1
ibition on that) but not passable to aggregate functions.
But then, shouldn't it be possible to write something like array_agg that
takes a set as input and returns an array, that is not an aggregate
function, and is callable from the columns-clause?
On Wed, Apr 24, 2013 at 2:26 PM,
This is just a guess (I haven't dug into the low-level page/disk access
Postgres code for Large Objects yet but if I'm right, the LO-based project
I'm working on will likely face the same issues you're seeing), but LOs
enjoy transactional behavior just like anything else (as far as I can tell
from
Hello,
I am working on an extension which defines a number of user-defined
functions which will operate on a common, custom data type to perform a
pipeline of transformations (the data type is the IN/OUT parameter for all
of the functions), eventually being supplied to a sink function which takes
Hmm, that might work - so allocate the values in a transaction-scoped
memory context?
But how would the hash table keys themselves be deleted? Is there some
callback API to
hook transaction completion?
On Wed, Jun 12, 2013 at 1:07 PM, Tom Lane wrote:
> Stephen Scheck writes:
> > &quo
IB_LINK = foo.o
Thanks for taking a look at this.
-Steve
On Wed, Jun 12, 2013 at 8:08 PM, Tom Lane wrote:
> Stephen Scheck writes:
> > However, whenever I run one of the UDTs defined in bar, I get this error
> > message:
>
> > dev=# SELECT * FROM test1 WHERE (info(
e
On Thu, Jun 13, 2013 at 7:38 AM, Tom Lane wrote:
> Stephen Scheck writes:
> > [postgres@dev1 lib]$ ldd bar.so
> > linux-vdso.so.1 => (0x7fff1c7ff000)
> > libc.so.6 => /lib64/libc.so.6 (0x7fa4c96ac000)
> > /lib64/ld-linux-x86
10 matches
Mail list logo
