Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane t...@sss.pgh.pa.us 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
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Dave Page dp...@pgadmin.org 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Dave Page dp...@pgadmin.org 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
On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org 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,
Dave Page dp...@pgadmin.org writes:
On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane t...@sss.pgh.pa.us 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
Dave Page dp...@pgadmin.org 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
On Wed, Jul 28, 2010 at 4:54 PM, Bruce Momjian br...@momjian.us 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
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 13/07/10 21:36, Tom Lane wrote:
Dave Pagedp...@pgadmin.org 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)
On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Robert Haas robertmh...@gmail.com writes:
On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org 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
On 13 July 2010 16:44, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org 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
On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:44, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org wrote:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly
On 13 July 2010 16:50, Dave Page dp...@pgadmin.org wrote:
On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:44, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 16:31, Dave Page dp...@pgadmin.org wrote:
We had a report of the above error from a
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown thombr...@gmail.com 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
On 13 July 2010 17:00, Dave Page dp...@pgadmin.org wrote:
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown thombr...@gmail.com 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
On 13 July 2010 17:01, Thom Brown thombr...@gmail.com wrote:
On 13 July 2010 17:00, Dave Page dp...@pgadmin.org wrote:
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown thombr...@gmail.com wrote:
I works if you use pr.proargdefaults so not unresolvable. Maybe it's
because it can't tell where the
Dave Page dp...@pgadmin.org 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
20 matches
Mail list logo
