Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> One might reasonably expect NULL there, but column_privilege_check
>> observes that you have table-level select privilege so it doesn't
>> bother to look up the column number. Not sure if this is worth
>> doing something about.
>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> OK, so here's a patch that I think does the right things.
> >> I noticed that has_foreign_data_wrapper_privilege() and some other
> >> recently-added members of the has_foo_pr
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> OK, so here's a patch that I think does the right things.
>> I noticed that has_foreign_data_wrapper_privilege() and some other
>> recently-added members of the has_foo_privilege family had not gotten
>> the word about not failing o
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Having said that, I'm fine with having it return NULL if the given
> >> attname matches an attisdropped column.
>
> > Ok, that's really all I was asking about.
>
> Ah, we we
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Having said that, I'm fine with having it return NULL if the given
>> attname matches an attisdropped column.
> Ok, that's really all I was asking about.
Ah, we were just talking past each other then :-(. That behavior existed
al
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > My complaint is specifically trying to do something like:
[...]
> That code is kinda broken anyway, because it won't survive relation drops
> either. What you *should* be writing is
Yes, I agree, but it still seems li
Stephen Frost writes:
> My complaint is specifically trying to do something like:
> =*# select *
> from
> pg_class
> join pg_attribute on (pg_class.oid = pg_attribute.attrelid)
> join pg_namespace on (pg_class.relnamespace = pg_n
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> You can't have it both ways. Either you throw an error if the name's
> >> not there, or you don't.
>
> > I'm not following why we couldn't handle a dropped column differentl
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> You can't have it both ways. Either you throw an error if the name's
>> not there, or you don't.
> I'm not following why we couldn't handle a dropped column differently.
Different from what? A name-based lookup isn't going to fi
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> The general plan in the has_foo_privilege functions is to throw errors for
> >> failing name-based lookups, but return null for failing numerically-based
> >> lookups (object
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The general plan in the has_foo_privilege functions is to throw errors for
>> failing name-based lookups, but return null for failing numerically-based
>> lookups (object OID or column number). I'm inclined to think we should
>> st
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> But it's not quite clear to me what we want the behavior for bad column
> >> name to be. A case could be made for either of:
> >>
> >> * If either the table OID is bad, or t
On 10/01/2018 02:41 PM, Stephen Frost wrote:
> Tom Lane (t...@sss.pgh.pa.us) wrote:
>> But it's not quite clear to me what we want the behavior for bad column
>> name to be. A case could be made for either of:
>>
>> * If either the table OID is bad, or the OID is OK but there's no such
>> column,
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> But it's not quite clear to me what we want the behavior for bad column
>> name to be. A case could be made for either of:
>>
>> * If either the table OID is bad, or the OID is OK but there's no such
>> column, return null.
>>
>>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Jaime Casanova writes:
> >> sqlsmith made it again, attached is the query (run against regression
> >> database) that makes the assert fail and the backtrace.
> >> this happens in head only (or at least 11 is fine).
>
> > Ah. Look
I wrote:
> Jaime Casanova writes:
>> sqlsmith made it again, attached is the query (run against regression
>> database) that makes the assert fail and the backtrace.
>> this happens in head only (or at least 11 is fine).
> Ah. Looks like the has_column_privilege stuff is incautious about whether
Jaime Casanova writes:
> sqlsmith made it again, attached is the query (run against regression
> database) that makes the assert fail and the backtrace.
> this happens in head only (or at least 11 is fine).
Ah. Looks like the has_column_privilege stuff is incautious about whether
it's handed a v
Hi,
sqlsmith made it again, attached is the query (run against regression
database) that makes the assert fail and the backtrace.
this happens in head only (or at least 11 is fine).
--
Jaime Casanova www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Trai
18 matches
Mail list logo
