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
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 to be
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 system tables are
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 it
-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 simple: add ability for engine to distinguish
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 permission.
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
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 presence
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 MyTable
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
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 column to
On Fri, Apr 5, 2013 at 11:34 AM, Doug Chamberlin
chamberlin.d...@gmail.comwrote:
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
2013/4/5 Ann Harrison a...@qbeast.net:
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.
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
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
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 to
2013/4/4 Vlad Khorsun hv...@users.sourceforge.net:
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
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
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.
Isn't
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 to
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
determine if
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
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
query text
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 throw
2013/4/4 Dmitry Yemanov firebi...@yandex.ru:
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.
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
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 for
On Thu, Apr 4, 2013 at 3:18 PM, Mark Rotteveel m...@lawinegevaar.nl 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
On 4-4-2013 21:25, Doug Chamberlin wrote:
On Thu, Apr 4, 2013 at 3:18 PM, Mark Rotteveel m...@lawinegevaar.nl
mailto:m...@lawinegevaar.nl 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
On Thu, Apr 4, 2013 at 3:36 PM, Mark Rotteveel m...@lawinegevaar.nl 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
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
On 04/04/2013 16:54, Doug Chamberlin wrote:
On Thu, Apr 4, 2013 at 3:36 PM, Mark Rotteveel m...@lawinegevaar.nl
mailto:m...@lawinegevaar.nl wrote:
I would say the expanded list would remain unmanageable and
unpredictable even if SELECT privileges would limit the expansion
of *.
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 and
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 back to
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 hele...@tpg.com.auschreef:
At 08:18 a.m. 5/04/2013, Mark Rotteveel wrote:
On Thu, Apr 4, 2013 at 3:29 PM, Sergey Mereutsa s...@dqteam.com 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,
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
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
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
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 to
40 matches
Mail list logo
