Prev: [HACKERS] ERROR: argument to pg_get_expr() must come from system catalogs
Next: bg worker: overview
From: Thom Brown on 13 Jul 2010 12:01
On 13 July 2010 17:00, Dave Page <dpage(a)pgadmin.org> wrote:
> On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown <thombrown(a)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 the column based on whether you're a superuser or not,
> just because it's not qualified?
>

Yeah see what you mean. Seems like a bug.

Thom

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Thom Brown on 13 Jul 2010 12:25
On 13 July 2010 17:01, Thom Brown <thombrown(a)gmail.com> wrote:
> On 13 July 2010 17:00, Dave Page <dpage(a)pgadmin.org> wrote:
>> On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown <thombrown(a)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 the column based on whether you're a superuser or not,
>> just because it's not qualified?
>>
>
> Yeah see what you mean. �Seems like a bug.
>
> Thom
>

And yes, as a result PgAdmin becomes very upset when not a superuser.
:( Kind of a show-stopper.

Thom

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 13 Jul 2010 14:36
Dave Page <dpage(a)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 pg_description des ON des.objoid=pr.oid

> Run as a regular user though, we get the error. If I remove the join,
> it works fine as the normal user. This is in a database owned by the
> regular user.

> Am I missing something obvious, or is there a bug here?

Yeah, it's a bug. The code Heikki added in parse_expr.c isn't allowing
for the possibility of join alias Vars. (There's another problem with
it too, which is you can trivially circumvent the check, just by
creating an operator based on pg_get_expr ...)

I wasn't terribly happy with that approach to begin with. I think we
need to rethink.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 16 Jul 2010 09:49
Heikki Linnakangas <heikki.linnakangas(a)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 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. Since we have no
near-term plans for new minor releases, I don't think it's urgent.

> 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.

Agreed, that seems like a better solution going forward than either of
the others.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 16 Jul 2010 12:51
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas <heikki.linnakangas(a)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 call functions in the future.

> The downside is that it might cause the approach used in the older releases to get less testing.

I hope we can get a better fix into the next 9.0 beta, so it will get
some field testing before any back-branch minor releases happen.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [HACKERS] ERROR: argument to pg_get_expr() must come from system catalogs
Next: bg worker: overview