On Mon, Jan 19, 2009 at 7:47 AM, Tom Lane wrote:
> I've applied a patch for this to HEAD and 8.3.
>
Cool, thanks Tom.
Just noting that I've tested your fix on both branches, and in both
cases pg_dump's output came out nice, clean and consistent.
Cheers,
BJ
--
Sent via pgsql-hackers mailing li
"Brendan Jurd" writes:
> On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane wrote:
>> Interesting --- it works as expected in 8.2. The problem seems to have
>> been created by the introduction of arrays over composites in 8.3.
> Congratulations on identifying the source!
I've applied a patch for this t
"Brendan Jurd" writes:
> Does this also explain the extra-weird output from HEAD, with the <=
> and = operators sorting earlier than the view, but the rest of the
> operators sorting after it?
No, that comes from the fact that we have dependencies on those two
operators (but not the whole opclass
On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane wrote:
> Interesting --- it works as expected in 8.2. The problem seems to have
> been created by the introduction of arrays over composites in 8.3.
Congratulations on identifying the source!
Does this also explain the extra-weird output from HEAD, with
"Brendan Jurd" writes:
> On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
>> However --- it's also the case that
>> pg_dump should dump all operators *and* operator classes before it gets
>> to views. So either you were doing something funny with the dump/reload
>> or else there's a circular de
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
> However --- it's also the case that
> pg_dump should dump all operators *and* operator classes before it gets
> to views. So either you were doing something funny with the dump/reload
> or else there's a circular dependency in your DB that pg_du
"Brendan Jurd" writes:
> On Sun, Jan 18, 2009 at 2:52 AM, Tom Lane wrote:
>> Is there a hash opclass for the type? 8.4 can group types that have
>> hash but not btree opclasses, but prior versions insisted on btree.
> Well I sure didn't create one. I've only been attempting to create a
> btree
On Sun, Jan 18, 2009 at 2:52 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>> Update. Turns out that 8.4 DOES know how to execute the view. If you
>> try to group on a user-defined composite type, 8.4 just goes ahead and
>> groups it, rather than giving the old "could not identify an ordering
>>
"Brendan Jurd" writes:
> Update. Turns out that 8.4 DOES know how to execute the view. If you
> try to group on a user-defined composite type, 8.4 just goes ahead and
> groups it, rather than giving the old "could not identify an ordering
> operator" error.
Is there a hash opclass for the type?
On Sun, Jan 18, 2009 at 1:41 AM, Brendan Jurd wrote:
> ... but I'm confused as to why 8.4
> doesn't freak out when told to create a view it doesn't actually know
> how to execute. Have the rules for evaluating views changed?
>
Update. Turns out that 8.4 DOES know how to execute the view. If yo
On Fri, Jan 16, 2009 at 10:23 AM, Tom Lane wrote:
> Looking at it some more, I notice that the SortGroupClause dependencies
> are on the individual operators, which probably isn't good enough: the
> operator *classes* have to exist or the parser will complain when trying
> to make sense of the vie
"Brendan Jurd" writes:
> On Fri, Jan 16, 2009 at 9:01 AM, Tom Lane wrote:
>> "Brendan Jurd" writes:
>>> * It seems there's no pg_depend entry for
>>> types/functions/operators/opclasses that the view depends on, unless
>>> they are part of the SELECT list.
>>
>> What PG version exactly?
> This
On Fri, Jan 16, 2009 at 9:01 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>> * It seems there's no pg_depend entry for
>> types/functions/operators/opclasses that the view depends on, unless
>> they are part of the SELECT list.
>
> What PG version exactly? We've been moving towards fuller
> rep
"Brendan Jurd" writes:
> I recently had pg_dump produce a non-restorable dump for one of my
> databases. I can't share the dump itself, but I can describe what
> went wrong. ...
> * It seems there's no pg_depend entry for
> types/functions/operators/opclasses that the view depends on, unless
> t
14 matches
Mail list logo
