Re: [Firebird-devel] RFC: non-expandable fields

On 06/04/13 10:42, Mark Rotteveel wrote: > The question is: if you don't have permissions for a column, are you > allowed to know of its existence? Drifting a bit OT, but one filesystem I knew years ago used ACLs and separated list and use permission. So if you had list permission you could see i

Re: [Firebird-devel] RFC: non-expandable fields

On 6-4-2013 12:24, Dimitry Sibiryakov wrote: > 06.04.2013 11:51, Dmitry Yemanov wrote: >> 06.04.2013 13:42, Mark Rotteveel wrote: >> >>> The question is: if you don't have permissions for a column, are you >>> allowed to know of its existence? >> >> I suppose the answer is "yes". Simply because sys

Re: [Firebird-devel] RFC: non-expandable fields

06.04.2013 11:51, Dmitry Yemanov wrote: > 06.04.2013 13:42, Mark Rotteveel wrote: > >> The question is: if you don't have permissions for a column, are you >> allowed to know of its existence? > > I suppose the answer is "yes". Simply because system tables are world > readable and this is unlikely

Re: [Firebird-devel] RFC: non-expandable fields

06.04.2013 13:42, Mark Rotteveel wrote: > The question is: if you don't have permissions for a column, are you > allowed to know of its existence? I suppose the answer is "yes". Simply because system tables are world readable and this is unlikely to be changed in the foreseeable future. Dmitry

Re: [Firebird-devel] RFC: non-expandable fields

On 5-4-2013 17:42, Dimitry Sibiryakov wrote: > 05.04.2013 17:34, Doug Chamberlin wrote: >> I would implement it so that if a user does not have SELECT permission on a >> field that any >> mention of that field in a SELECT statement is an outright error for that >> user. Just as if >> the field di

Re: [Firebird-devel] RFC: non-expandable fields

2013/4/5 Ann Harrison : > I think that's the intention of the standard, but like Dmitry, I have been > unable to find a clear statement to that effect. If it matters to anybody, > I've got a couple of friends who are serious standards addicts and I could > ask for a reference there. The Red Datab

Re: [Firebird-devel] RFC: non-expandable fields

On Fri, Apr 5, 2013 at 11:34 AM, Doug Chamberlin wrote: > >> I would implement it so that if a user does not have SELECT permission on > a field that any mention of that field in a SELECT statement is an outright > error for that user. Just as if the field did not exist. > > I think that's the int

Re: [Firebird-devel] RFC: non-expandable fields

>Bad idea, IMHO. I predict a lot of support request "I see in SHOW TABLE > that > field exists, but select throw me error that it doesn't". Error message must > clearly state its > reason: "not enough rights to read this field". That could be addressed by adding "Permission" or "Accessible"

Re: [Firebird-devel] RFC: non-expandable fields

05.04.2013 17:34, Doug Chamberlin wrote: > I would implement it so that if a user does not have SELECT permission on a > field that any > mention of that field in a SELECT statement is an outright error for that > user. Just as if > the field did not exist. Bad idea, IMHO. I predict a lot of

Re: [Firebird-devel] RFC: non-expandable fields

On Fri, Apr 5, 2013 at 10:52 AM, Alexandre Benson Smith < ibl...@thorsoftware.com.br> wrote: > I don't think trowing an error is the best, the select could be > performed but no value returned for that column. The engine should > provide mechanisms to treat it as a whole like > > select * from MyT

Re: [Firebird-devel] RFC: non-expandable fields

Em 4/4/2013 22:53, Doug Chamberlin escreveu: > So forget the previous discussion for a moment. Especially any parts > about the best ways to implement replication and SELECT * problems. > > Without getting into the details of the use case, essentially the OP > asked for a way to suppress the pres

Re: [Firebird-devel] RFC: non-expandable fields

05.04.2013 12:27, Alex Peshkoff wrote: > But if we forget about hiding something from people - is not it useful > to change behavior of 'select *' in a case when some fields are not > selectable? I don't mind, it just won't solve the problem being discussed here. Dmitry --

Re: [Firebird-devel] RFC: non-expandable fields

On 04/05/13 07:50, Dmitry Yemanov wrote: > 05.04.2013 5:53, Doug Chamberlin wrote: > >> Seems to me the leading solution would be to extend SQL compliance for >> permissions on fields to the SELECT statement such that users would not >> be able to SELECT fields for which they did not have permissio

Re: [Firebird-devel] RFC: non-expandable fields

> -Oprindelig meddelelse- > Fra: Leyne, Sean [mailto:s...@broadviewsoftware.com] > Sendt: 4. april 2013 17:59 > Til: For discussion among Firebird Developers > Emne: Re: [Firebird-devel] RFC: non-expandable fields > > > > > So, the proposition is sim

Re: [Firebird-devel] RFC: non-expandable fields

05.04.2013 5:53, Doug Chamberlin wrote: > Seems to me the leading solution would be to extend SQL compliance for > permissions on fields to the SELECT statement such that users would not > be able to SELECT fields for which they did not have permission. Thinking twice, I see that it's not going t

Re: [Firebird-devel] RFC: non-expandable fields

So forget the previous discussion for a moment. Especially any parts about the best ways to implement replication and SELECT * problems. Without getting into the details of the use case, essentially the OP asked for a way to suppress the presence of selected fields in tables. Seems to me the leadi

Re: [Firebird-devel] RFC: non-expandable fields

> Back to the question, Vlad asked (we are already discussing how it could be > done and whether one or the other approach would fit): Is this a feature, > Firebird should support? > > I'm not familiar enough with the SQL-specification to answer whether it's > standard compliant or not, but if i

Re: [Firebird-devel] RFC: non-expandable fields

Back to the question, Vlad asked (we are already discussing how it could be done and whether one or the other approach would fit): Is this a feature, Firebird should support? I'm not familiar enough with the SQL-specification to answer whether it's standard compliant or not, but if it isn't, I wou

Re: [Firebird-devel] RFC: non-expandable fields

On Thu, Apr 4, 2013 at 3:29 PM, Sergey Mereutsa wrote: > Hello Vlad and all, > > IMHO, the easiest way to implement this is to make all fields with > prefix "RDB$" (or whatever) hidden by default. Untill you do not > address to those fields directly - they are ignored by the engine, > when data i

Re: [Firebird-devel] RFC: non-expandable fields

To be clear I wasn't talking about removing support for SELECT *, just that I don't see the point of having some non-standard mechanism to exclude columns for the expansion of *. Mark -- Mark Rotteveel Helen Borrie schreef: >At 08:18 a.m. 5/04/2013, Mark Rotteveel wrote: > >>On the other han

Re: [Firebird-devel] RFC: non-expandable fields

> >On the other hand: using select * for anything other than ad-hoc > >queries is bad. Should we support that? > > AFAIK, there's a long legacy, in Delphi components at least, of using SELECT * > as the dataset spec for emulating a "table" component (TTable and > derivatives). Sure, this goes b

Re: [Firebird-devel] RFC: non-expandable fields

At 08:18 a.m. 5/04/2013, Mark Rotteveel wrote: >On the other hand: using select * for anything other than ad-hoc queries >is bad. Should we support that? AFAIK, there's a long legacy, in Delphi components at least, of using SELECT * as the dataset spec for emulating a "table" component (TTable

Re: [Firebird-devel] RFC: non-expandable fields

On 04/04/2013 16:54, Doug Chamberlin wrote: > On Thu, Apr 4, 2013 at 3:36 PM, Mark Rotteveel > wrote: > > I would say the expanded list would remain unmanageable and > unpredictable even if SELECT privileges would limit the expansion > of *. > > > I didn't

Re: [Firebird-devel] RFC: non-expandable fields

Hello Vlad and all, IMHO, the easiest way to implement this is to make all fields with prefix "RDB$" (or whatever) hidden by default. Untill you do not address to those fields directly - they are ignored by the engine, when data is fetched. But the problem is a bit deeper. How to deal with those

Re: [Firebird-devel] RFC: non-expandable fields

On Thu, Apr 4, 2013 at 3:36 PM, Mark Rotteveel wrote: > I would say the expanded list would remain unmanageable and > unpredictable even if SELECT privileges would limit the expansion of *. > I didn't say it solved the whole problem. I said it was a step toward solving the problem. The quest fo

Re: [Firebird-devel] RFC: non-expandable fields

On 4-4-2013 21:25, Doug Chamberlin wrote: > On Thu, Apr 4, 2013 at 3:18 PM, Mark Rotteveel > wrote: > > On the other hand: using select * for anything other than ad-hoc queries > is bad. Should we support that? > > > Isn't it bad ONLY because the expanded list

Re: [Firebird-devel] RFC: non-expandable fields

On Thu, Apr 4, 2013 at 3:18 PM, Mark Rotteveel wrote: > On the other hand: using select * for anything other than ad-hoc queries > is bad. Should we support that? > Isn't it bad ONLY because the expanded list is unmanagable and unpredictable? This proposal is a step toward removing that problem

Re: [Firebird-devel] RFC: non-expandable fields

On 4-4-2013 20:57, Dmitry Yemanov wrote: > 04.04.2013 19:41, Björn Reimer wrote: >> >> Can't you realize this with removing select permission for a >> column? Of course it's not yet possible as only update and reference >> are allowed currently. > > IIRC, the SQL spec declares select permissions

Re: [Firebird-devel] RFC: non-expandable fields

04.04.2013 23:03, Roman Simakov wrote: > In RedDatabase we do not expand * in query "select * from T" into all > fields of T but only in fields which user can access. > IMO produce an error is incorrect in this case. User just want to see > all available fields. > Also IMO it can be a solution of

Re: [Firebird-devel] RFC: non-expandable fields

2013/4/4 Dmitry Yemanov : > IIRC, the SQL spec declares select permissions for columns. And they're > surely intended to throw errors, not to hide something. In RedDatabase we do not expand * in query "select * from T" into all fields of T but only in fields which user can access. IMO produce an e

Re: [Firebird-devel] RFC: non-expandable fields

04.04.2013 20:56, Dmitry Yemanov wrote: > AFAIU, the point is to add a replication into a schema without requiring > to change that schema. I would hate to be forced wrapping my selects > into views just to please some replication solution. So no, views are > not applicable here. Rename table a

Re: [Firebird-devel] RFC: non-expandable fields

04.04.2013 19:41, Björn Reimer wrote: > > Can't you realize this with removing select permission for a > column? Of course it's not yet possible as only update and reference > are allowed currently. IIRC, the SQL spec declares select permissions for columns. And they're surely intended to thro

Re: [Firebird-devel] RFC: non-expandable fields

04.04.2013 19:58, Leyne, Sean wrote: > >>So, the proposition is simple: add ability for engine to distinguish such >> service fields and not include it into auto expanded list of fields for >> table or >> view at the queries above. I.e. service fields is fully accessible if >> present in >> q

Re: [Firebird-devel] RFC: non-expandable fields

On 4-4-2013 17:33, Thomas Steinmaurer wrote: > IMHO a hack, which shouldn't go into a public release. But that's just > my personal opinion. ;-) Agreed. Mark -- Mark Rotteveel -- Minimize network downtime and maximize t

Re: [Firebird-devel] RFC: non-expandable fields

On 04/04/2013 17:11, Paul Beach wrote: >> i wrote this RFC by request of one local company which have (as many others) >> wrote own replicator and got some issues which could be resolved very easy >> with a little support from the Firebird engine side. I think we could >> discuss it and >> determi

Re: [Firebird-devel] RFC: non-expandable fields

On 04/04/2013 12:58, Leyne, Sean wrote: > >> So, the proposition is simple: add ability for engine to distinguish such >> service fields and not include it into auto expanded list of fields for >> table or >> view at the queries above. I.e. service fields is fully accessible if >> present in >>

Re: [Firebird-devel] RFC: non-expandable fields

> i wrote this RFC by request of one local company which have (as many others) > wrote own replicator and got some issues which could be resolved very easy > with a little support from the Firebird engine side. I think we could discuss > it and > determine if requested feature could add some value

Re: [Firebird-devel] RFC: non-expandable fields

> So, the proposition is simple: add ability for engine to distinguish such > service fields and not include it into auto expanded list of fields for table > or > view at the queries above. I.e. service fields is fully accessible if present > in > query text explicitly and "hidden" otherwise.

Re: [Firebird-devel] RFC: non-expandable fields

> Hi all, > i wrote this RFC by request of one local company which have (as many others) > wrote own replicator and got some issues which could be resolved very easy > with a little support from the Firebird engine side. I think we could discuss > it and > determine if requested feature coul

Re: [Firebird-devel] RFC: non-expandable fields

2013/4/4 Vlad Khorsun : > So, the proposition is simple: add ability for engine to distinguish such > service > fields and not include it into auto expanded list of fields for table or view > at the > queries above. I.e. service fields is fully accessible if present in query > text explicitly

Re: [Firebird-devel] RFC: non-expandable fields

> i wrote this RFC by request of one local company which have (as many others) > wrote own replicator and got some issues which could be resolved very easy > with a little support from the Firebird engine side. I think we could discuss > it and > determine if requested feature could add some value

Re: [Firebird-devel] RFC: non-expandable fields

Hi Vlad, I see two aspects: - With "RDB$DB_KEY" there already is a hidden field (though this one is not in 'RDB$RELATION_FIELDS'), so it might not be that surprising to have this beeing a feature of FB. - On the other hand, I would not like neither your statement a) nor b) in our code, nor do I s

[Firebird-devel] RFC: non-expandable fields

Hi all, i wrote this RFC by request of one local company which have (as many others) wrote own replicator and got some issues which could be resolved very easy with a little support from the Firebird engine side. I think we could discuss it and determine if requested feature could add some v