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
15 matches
Mail list logo
