On Sat, 15 Oct 2016 22:24:31 -0400,
Tom Lane wrote:
> Sebastian Luque writes:
>> Tom Lane wrote:
>>> Are you in a position to apply patches? It's a one-line fix:
>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dca25c2562199ce1e7e26367613912a8eadbbde8
>> I'd like to try
Sebastian Luque writes:
> Tom Lane wrote:
>> Are you in a position to apply patches? It's a one-line fix:
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dca25c2562199ce1e7e26367613912a8eadbbde8
> I'd like to try this by obtaining the Debian source package, downloading
> a
On Sun, 09 Oct 2016 16:00:21 -0400,
Tom Lane wrote:
> Are you in a position to apply patches? It's a one-line fix:
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dca25c2562199ce1e7e26367613912a8eadbbde8
I'd like to try this by obtaining the Debian source package, downloadi
On Sun, Oct 9, 2016 at 10:10 PM, Sebastian P. Luque wrote:
> On Sun, 09 Oct 2016 16:00:21 -0400,
> Tom Lane wrote:
>
>> "Sebastian P. Luque" writes:
>>> Tom Lane wrote:
On closer inspection, the error is only in the
aggregate-used-as-window-function case, not plain aggregation.
>
>>>
On Sun, 09 Oct 2016 16:00:21 -0400,
Tom Lane wrote:
> "Sebastian P. Luque" writes:
>> Tom Lane wrote:
>>> On closer inspection, the error is only in the
>>> aggregate-used-as-window-function case, not plain aggregation.
>> Yes, I see the same phenomenon. Could someone suggest a workaround
>>
On 10/09/2016 09:40 AM, Tom Lane wrote:
Adrian Klaver writes:
On 10/09/2016 08:46 AM, Tom Lane wrote:
Clearly a bug --- the wrong type OIDs are being passed down to
array_append. It should be told that it's getting called as
For my edification, why does this work?:
On closer inspection,
"Sebastian P. Luque" writes:
> Tom Lane wrote:
>> On closer inspection, the error is only in the
>> aggregate-used-as-window-function case, not plain aggregation.
> Yes, I see the same phenomenon. Could someone suggest a workaround
> until this is fixed? I'm under the gun to submit output tabl
On Sun, 09 Oct 2016 12:40:09 -0400,
Tom Lane wrote:
> Adrian Klaver writes:
>> On 10/09/2016 08:46 AM, Tom Lane wrote:
>>> Clearly a bug --- the wrong type OIDs are being passed down to
>>> array_append. It should be told that it's getting called as
>> For my edification, why does this work?:
Adrian Klaver writes:
> On 10/09/2016 08:46 AM, Tom Lane wrote:
>> Clearly a bug --- the wrong type OIDs are being passed down to
>> array_append. It should be told that it's getting called as
> For my edification, why does this work?:
On closer inspection, the error is only in the
aggregate-us
On 10/09/2016 08:46 AM, Tom Lane wrote:
Seb writes:
Any thoughts on what has changed that is leading to this failure?
Clearly a bug --- the wrong type OIDs are being passed down to
array_append. It should be told that it's getting called as
(angle_vectors[], angle_vectors) returns a
Seb writes:
> Any thoughts on what has changed that is leading to this failure?
Clearly a bug --- the wrong type OIDs are being passed down to
array_append. It should be told that it's getting called as
(angle_vectors[], angle_vectors) returns angle_vectors[]
but what it's actually get
On 10/09/2016 08:01 AM, Sebastian P. Luque wrote:
On Sun, 9 Oct 2016 06:44:10 -0700,
Adrian Klaver wrote:
[...]
Not sure. When I tried using the above(on 9.5) it failed during the
CREATE OR REPLACE FUNCTION public.angle_vectors_avg stage with:
ERROR: type "vector" does not exist
So whe
On Sun, 9 Oct 2016 06:44:10 -0700,
Adrian Klaver wrote:
[...]
> Not sure. When I tried using the above(on 9.5) it failed during the
> CREATE OR REPLACE FUNCTION public.angle_vectors_avg stage with:
> ERROR: type "vector" does not exist
> So where is that coming from in your setup?
Aw nuts, I
On 10/08/2016 08:21 PM, Seb wrote:
Hello,
Until I upgraded to PostgreSQL 9.6, a custom average function was
working well as a window function. It's meant to average a composite
type:
CREATE TYPE public.angle_vectors AS
(x double precision,
y double precision);
COMMENT ON TYPE public.ang
Hello,
Until I upgraded to PostgreSQL 9.6, a custom average function was
working well as a window function. It's meant to average a composite
type:
CREATE TYPE public.angle_vectors AS
(x double precision,
y double precision);
COMMENT ON TYPE public.angle_vectors
IS 'This type holds the
15 matches
Mail list logo