Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Dave Page writes:
> >>> Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
> >>> be the case, or is it something else?
> >>
> >> He's mistaken. The bug is in all the branches, but there have been no
> >> releases
Bruce Momjian writes:
> Tom Lane wrote:
>> Dave Page writes:
>>> Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
>>> be the case, or is it something else?
>>
>> He's mistaken. The bug is in all the branches, but there have been no
>> releases with it except 9.0beta3. I wil
Tom Lane wrote:
> Dave Page writes:
> > On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane wrote:
> >> I've applied a (rather hurried) patch for this for 9.0beta4.
>
> > Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
> > be the case, or is it something else?
>
> He's mistaken. Th
Dave Page writes:
> On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane wrote:
>> I've applied a (rather hurried) patch for this for 9.0beta4.
> Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
> be the case, or is it something else?
He's mistaken. The bug is in all the branches, bu
On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane wrote:
> Dave Page writes:
>> We had a report of the above error from a pgAdmin user testing
>> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
>> as a superuser:
>
>> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regcl
Dave Page writes:
> We had a report of the above error from a pgAdmin user testing
> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
> as a superuser:
> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
> FROM pg_proc pr
> LEFT OUTER JOIN pg_descriptio
On Wed, Jul 28, 2010 at 4:54 PM, Bruce Momjian wrote:
> Are we basically leaving pgAdmin in this state until we come up with a
> fix and need a new minor release? We pride ourselves in not introducing
> breakage in minor releases, but it has certainly happened in this case,
> and it is making pgA
I wrote:
> Heikki Linnakangas writes:
>> Do you want to go ahead with your plan of changing what's passed in
>> FuncInfo? I won't object if you want to do it, but I wouldn't feel
>> comfortable with backporting such big changes myself.
> I will take a look at it, but not right away.
I spent so
Robert Haas writes:
> On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
> wrote:
>> If we continue with the approach I took, we should implement the suggestion
>> to create a new data type for this in 9.1. That would be more waterproof
>> than the changes I made, if we introduce new ways to call
Heikki Linnakangas writes:
> On 13/07/10 21:36, Tom Lane wrote:
>> I wasn't terribly happy with that approach to begin with. I think we
>> need to rethink.
> Do you want to go ahead with your plan of changing what's passed in
> FuncInfo? I won't object if you want to do it, but I wouldn't feel
On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
wrote:
> If we continue with the approach I took, we should implement the suggestion
> to create a new data type for this in 9.1. That would be more waterproof than
> the changes I made, if we introduce new ways to call functions in the future.
T
On 13/07/10 21:36, Tom Lane wrote:
Dave Page writes:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
Dave Page writes:
> We had a report of the above error from a pgAdmin user testing
> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
> as a superuser:
> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
> FROM pg_proc pr
> LEFT OUTER JOIN pg_descriptio
On 13 July 2010 17:01, Thom Brown wrote:
> On 13 July 2010 17:00, Dave Page wrote:
>> On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown wrote:
>>
>>> I works if you use pr.proargdefaults so not unresolvable. Maybe it's
>>> because it can't tell where the column's coming from at that point?
>>
>> Hmm,
On 13 July 2010 17:00, Dave Page wrote:
> On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown wrote:
>
>> I works if you use pr.proargdefaults so not unresolvable. Maybe it's
>> because it can't tell where the column's coming from at that point?
>
> Hmm, so it does. It still seems like a bug though - wh
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown wrote:
> I works if you use pr.proargdefaults so not unresolvable. Maybe it's
> because it can't tell where the column's coming from at that point?
Hmm, so it does. It still seems like a bug though - why should it be
able to resolve the column based o
On 13 July 2010 16:50, Dave Page wrote:
> On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown wrote:
>> On 13 July 2010 16:44, Thom Brown wrote:
>>> On 13 July 2010 16:31, Dave Page wrote:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simpl
On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown wrote:
> On 13 July 2010 16:44, Thom Brown wrote:
>> On 13 July 2010 16:31, Dave Page wrote:
>>> We had a report of the above error from a pgAdmin user testing
>>> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
>>> as a superuse
On 13 July 2010 16:44, Thom Brown wrote:
> On 13 July 2010 16:31, Dave Page wrote:
>> We had a report of the above error from a pgAdmin user testing
>> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
>> as a superuser:
>>
>> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg
On 13 July 2010 16:31, Dave Page wrote:
> We had a report of the above error from a pgAdmin user testing
> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
> as a superuser:
>
> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
> FROM pg_proc pr
> LEFT OUT
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
Run
21 matches
Mail list logo
