Alvaro Herrera writes:
> It seems there's something wrong here.
Ah, it's a bug in array_unnest: if its argument is toasted, it detoasts
it into function-local memory, and then tries to keep a pointer to that
across calls. Boo. Will fix.
regards, tom lane
--
Sent via p
Alvaro Herrera wrote:
> Tom Lane wrote:
> > > As it happens, I need to use it in the pg_dump support for TOAST
> > > reloptions.
> >
> > Maybe something involving
> > ARRAY(SELECT foo(x) FROM UNNEST(arrayvariable) x)
>
> Hmm, I'll have a look at this.
It seems there's something wrong here.
Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm wondering why don't we expose the array_map() function to the SQL
> > level.
>
> It requires some notion of "reference to function", which doesn't really
> exist in SQL. (Please don't say you're going to pass it a function
> OID.)
regproc maybe?
Alvaro Herrera writes:
> I'm wondering why don't we expose the array_map() function to the SQL
> level.
It requires some notion of "reference to function", which doesn't really
exist in SQL. (Please don't say you're going to pass it a function
OID.)
> As it happens, I need to use it in the pg_d
Hi,
I'm wondering why don't we expose the array_map() function to the SQL
level. As it happens, I need to use it in the pg_dump support for TOAST
reloptions.
Why? Well, TOAST reloptions are stored in the pg_class tuple of the
TOAST table, so when I extract them directly, it looks like a simple
