ITAGAKI Takahiro wrote:
> - Postgres interprets 'on' as true and 'off' as false in configuration
> parameters, but they are not accepted in sql-boolean.
> Is it a design? or should we add a parser for 'on' and 'off' ?
> I'd like to allow 'on' and 'off' in sql-boolean, too.
Here is
Jaime Casanova wrote:
On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas wrote:
With reference to row-level security, most of the complaining about
this feature has been along the lines of "I don't like the idea that
rows get filtered from my result-set that I didn't ask to have
filtered".
yeah! b
ITAGAKI Takahiro writes:
> We already have some codes to avoid -0 float8um (unary minus),
> but there are no protection in trunc(), ceil() and round() at least.
I looked into the CVS history to find out when the anti-minus-zero code
got put into float8um. It seems to have been done by Tom Lockha
Robert Haas wrote:
On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane wrote:
Robert Haas writes:
I'm a little bothered by this issue with respect to INSERT, UPDATE,
and DELETE, since it's possible that I have permission to see rows but
not updated them, and it would be a little weird if select and up
Robert Haas wrote:
I'm a little bothered by this issue with respect to INSERT, UPDATE,
and DELETE, since it's possible that I have permission to see rows but
not updated them, and it would be a little weird if select and update
with equivalent where clauses operated on different sets of records
(
Robert Haas wrote:
On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane wrote:
I haven't seen anyone present a shred of evidence that this would be
the case in SE-PostgreSQL.
Sorry, but the burden of proof is in the other direction.
In any case, this was already discussed in detail in previous threads.
Peter Eisentraut wrote:
> Tom Lane wrote:
> >> Is this acceptable to everyone? We could name the option
> >> -u/--upgrade-compatible.
> >
> > If the switch is specifically for pg_upgrade support (enabling this as
> > well as any other hacks we find necessary), which seems like a good
> > idea, th
It is incorrect.
It seems to me you confound a covert channel and granularity in access
controls. The purpose of row-level security is to provide users more
flexibility in access controls, not related to covert channels.
No, I claim it's you that's confounding the data hiding scheme with
row-lev
Tom Lane wrote:
> Martijn van Oosterhout writes:
>> One thing I keep missing in this discussion: the term "row-level
>> security" in the above senstence in not the important part. Right now
>> you can revoke SELECT permission on a table with a foreign key and it
>> will still prevent UPDATEs and D
I reported the following bug to -bugs, and I'd like to discuss
whether we need to fix the issue or how to fix it.
"ITAGAKI Takahiro" wrote:
> Bug reference: 4660
> PostgreSQL version: 8.3.3
> Operating system: Fedora 8
> Description:float functions return -0
> Details:
> Float8 ve
ITAGAKI Takahiro writes:
> Tom Lane wrote:
>> ITAGAKI Takahiro writes:
>>> - Are there any limitations in casting to anyelement?
>>
>> It's a no-op ... probably we shouldn't even let you do it, if the
>> lack of an error leaves room for such misinterpretation as this.
>> anyelement and friends
Tom Lane wrote:
> ITAGAKI Takahiro writes:
> > - Are there any limitations in casting to anyelement?
>
> It's a no-op ... probably we shouldn't even let you do it, if the
> lack of an error leaves room for such misinterpretation as this.
> anyelement and friends are placeholders for use in f
ITAGAKI Takahiro wrote:
> The attached is a patch to change 3 things:
> - Reject toast.fillfactor.
> - Modify relopt_kind to bit flags.
> - Report relation type on "unrecognized parameter" errors.
I registered the patch as an open item:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_
Cédric Villemain wrote:
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (pg_restore) to run simultaneously. If the -j
option is given without an argument, pg_restore will not limit the number of
jobs that can run simultaneously.
Quite apart from anything else, this descripti
Hello
I found BNF for SQL 2003 and I found there some small difference.
Standard use keyword ESCAPE, but PostgreSQL use keybord UESCAPE.
Anybody knows reason?
::=
[ ]
U [ ... ]
[ { [ ... ] }... ]
[ ESCAPE ]
thank you
Pavel Stehule
--
Sent v
2009/2/16 Tom Lane :
> Pavel Stehule writes:
>> Next sample of parser hook using:
>> attachment contains module that transform every empty string to null.
>> I am not sure, if this behave is exactly compatible with Oracle,
>
> Surely a parser hook like this would have nothing whatsoever to do
> wi
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
>> 2009/2/16 Sam Mason :
>> > But to do it properly inside PG would be difficult; how would your hooks
>> > know to transform:
>> >
>> > SELECT s FROM foo WHERE s IS NULL;
>> >
>> > into:
>> >
>> > SELECT s FRO
On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
> 2009/2/16 Sam Mason :
> > But to do it properly inside PG would be difficult; how would your hooks
> > know to transform:
> >
> > SELECT s FROM foo WHERE s IS NULL;
> >
> > into:
> >
> > SELECT s FROM foo WHERE (s = '' OR s IS NULL)
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
>> 2009/2/16 Sam Mason :
>> > On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
>> >> so these modules (decode, oraemptystr) decrease differences between
>> >> PostgreSQL and Oracle.
>> >
>> > wouldn
A couple of thoughts:
First off, I think the inclusion of row level security and an
unprecendented integration with OS level security are a stunning
example of what makes Open Source so much cooler than closed source
products. Great job! (and the speed of refactoring the patches was
pretty stunning
On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
> 2009/2/16 Sam Mason :
> > On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
> >> so these modules (decode, oraemptystr) decrease differences between
> >> PostgreSQL and Oracle.
> >
> > wouldn't it be better/easier to exte
On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas wrote:
>
> With reference to row-level security, most of the complaining about
> this feature has been along the lines of "I don't like the idea that
> rows get filtered from my result-set that I didn't ask to have
> filtered".
yeah! because was filte
On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm a little bothered by this issue with respect to INSERT, UPDATE,
>> and DELETE, since it's possible that I have permission to see rows but
>> not updated them, and it would be a little weird if select and update
>> with
Robert Haas writes:
> I'm a little bothered by this issue with respect to INSERT, UPDATE,
> and DELETE, since it's possible that I have permission to see rows but
> not updated them, and it would be a little weird if select and update
> with equivalent where clauses operated on different sets of r
On Mon, Feb 16, 2009 at 11:21 AM, Greg Stark wrote:
> On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas wrote:
>>
>> I'm not sure I understand what you mean by that. I expect that if I
>> deny a particular user access to SELECT from a particular table the
>> system will throw a permissions error if t
On 02/16/2009 04:23 PM, Kevin Grittner wrote:
Tom Lane wrote:
We have seen no evidence that anyone has a worked-out
set of design rules that make a SE-Postgres database secure against
these issues, so the whole thing is pie in the sky.
I've seen several mentions of the rule "Don't use a column
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas wrote:
>
> I'm not sure I understand what you mean by that. I expect that if I
> deny a particular user access to SELECT from a particular table the
> system will throw a permissions error if that user later enters
> "SELECT * FROM ". I don't expect t
Joshua D. Drake wrote:
> Thanks for the work around, but that is ridiculous. I still say this is
> a bug.
Yes, which is why we fixed it on 8.4 by dropping pg_autovacuum. (As
Jaime and Tom say, it's actually pilot error, but the UI is crap so we
fixed it.)
--
Alvaro Herrera
On Mon, Feb 16, 2009 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> 2. Foreign-key constraints.
>> (A) If you have update or delete privileges on a table that is
>> referenced by foreign keys, you might be able to infer the existence
>> of a hidden, referring row because your update or del
On Mon, Feb 16, 2009 at 12:10 PM, Cédric Villemain
wrote:
>>
>> is -j already affected ?
>
> else (like make):
>
> -j [jobs], --jobs[=jobs]
> Specifies the number of jobs (pg_restore) to run simultaneously. If the -j
> option is given without an argument, pg_restore will not limit the number
Robert Haas writes:
> 2. Foreign-key constraints.
> (A) If you have update or delete privileges on a table that is
> referenced by foreign keys, you might be able to infer the existence
> of a hidden, referring row because your update or delete fails.
Also the other direction (insert or update on
ITAGAKI Takahiro writes:
> - Are there any limitations in casting to anyelement?
It's a no-op ... probably we shouldn't even let you do it, if the
lack of an error leaves room for such misinterpretation as this.
anyelement and friends are placeholders for use in function
declarations, not real
On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane wrote:
>> I haven't seen anyone present a shred of evidence that this would be
>> the case in SE-PostgreSQL.
>
> Sorry, but the burden of proof is in the other direction.
>
> In any case, this was already discussed in detail in previous threads.
> It's po
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
>> 2009/2/16 Sam Mason :
>> > On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
>> >> attachment contains module that transform every empty string to null.
>> >
>> > Why would anyone ever want to do
"Kevin Grittner" writes:
> Tom Lane wrote:
>> We have seen no evidence that anyone has a worked-out
>> set of design rules that make a SE-Postgres database secure against
>> these issues, so the whole thing is pie in the sky.
> I've seen several mentions of the rule "Don't use a column contain
>>> Tom Lane wrote:
> We have seen no evidence that anyone has a worked-out
> set of design rules that make a SE-Postgres database secure against
> these issues, so the whole thing is pie in the sky.
I've seen several mentions of the rule "Don't use a column containing
data you want to secure a
Robert Haas writes:
> ... so the question is not "Are there covert channels?" but "Are the
> covert channels sufficiently large so as to render the system not
> useful in the real world?".
Fair enough.
> I haven't seen anyone present a shred of evidence that this would be
> the case in SE-Postgr
>>> Andres Freund wrote:
> I guess he is talking about 2009PA23 being a foreign key - about
> which you could get information via the aforementioned covert
channels,
> even if you cannot read that row.
Exactly. Sorry I didn't make that more clear.
-Kevin
--
Sent via pgsql-hackers mai
Pavel Stehule writes:
> Next sample of parser hook using:
> attachment contains module that transform every empty string to null.
> I am not sure, if this behave is exactly compatible with Oracle,
Surely a parser hook like this would have nothing whatsoever to do
with Oracle's behavior.
On Mon, Feb 16, 2009 at 9:53 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Gregory Stark wrote:
>>> And it doesn't accomplish anything since the covert
>>> channels it attempts to address are still open.
>
>> Hyperbole. We're not very likely to go the SE-* route, but I can say
>> that we've
>>> Tom Lane wrote:
> "Kevin Grittner" writes:
>> Gregory Stark wrote:
>>> And it doesn't accomplish anything since the covert
>>> channels it attempts to address are still open.
>
>> Hyperbole. We're not very likely to go the SE-* route, but I can
say
>> that we've got some of the issues i
Hi,
On 02/16/2009 03:53 PM, Tom Lane wrote:
Hyperbole. We're not very likely to go the SE-* route, but I can say
that we've got some of the issues it addresses, and it is a very
different thing for someone to know, for example, that there is a
paternity case 2009PA23 in a county, and for th
>> Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
>> eliminate information leaks via such kind of covert channels, so they
>> don't violate any specifications of them. Thus, it is not a problem.
>
> If that's true then I don't see why we would try to automatically hide reco
Martijn van Oosterhout writes:
> One thing I keep missing in this discussion: the term "row-level
> security" in the above senstence in not the important part. Right now
> you can revoke SELECT permission on a table with a foreign key and it
> will still prevent UPDATEs and DELETEs of the primary
"Kevin Grittner" writes:
> Gregory Stark wrote:
>> And it doesn't accomplish anything since the covert
>> channels it attempts to address are still open.
> Hyperbole. We're not very likely to go the SE-* route, but I can say
> that we've got some of the issues it addresses, and it is a very
>
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
> 2009/2/16 Sam Mason :
> > On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
> >> attachment contains module that transform every empty string to null.
> >
> > Why would anyone ever want to do this? This would appear to b
On Mon, Feb 16, 2009 at 12:08 PM, KaiGai Kohei wrote:
This is the same "covert channel", so why is it a problem for
SE-Postgres and not for normal Postgres?
>>>
>>> Please note that I don't consider it is a problem, even if SE-PostgreSQL.
>>>
>>> Both of SE-PostgreSQL and vanilla Postgre
On Mon, Feb 16, 2009 at 10:54:32AM +, Gregory Stark wrote:
> > Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
> > eliminate information leaks via such kind of covert channels, so they
> > don't violate any specifications of them. Thus, it is not a problem.
>
> If that'
2009/2/16 Sam Mason :
> On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
>> attachment contains module that transform every empty string to null.
>
> Why would anyone ever want to do this? This would appear to break all
> sorts of things in very non-obvious ways:
I agree, so this be
On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
> attachment contains module that transform every empty string to null.
Why would anyone ever want to do this? This would appear to break all
sorts of things in very non-obvious ways:
SELECT CASE s WHEN '' THEN 'empty string' ELSE
>>> Gregory Stark wrote:
>And it doesn't accomplish anything since the covert
>channels it attempts to address are still open.
Hyperbole. We're not very likely to go the SE-* route, but I can say
that we've got some of the issues it addresses, and it is a very
different thing for someo
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle, but
for first iteration it is good.
postgres=# select length('') is null;
?column?
--
t
(1 row)
I thing, so this shou
This is the same "covert channel", so why is it a problem for
SE-Postgres and not for normal Postgres?
Please note that I don't consider it is a problem, even if SE-PostgreSQL.
Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
eliminate information leaks via such kind of co
On Mon, Feb 16, 2009 at 12:39:32PM +0200, Peter Eisentraut wrote:
> On Monday 16 February 2009 12:06:55 Michael Meskes wrote:
> > On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote:
> > > Will a program built with ecpg 8.4 run against a 7.4 server work the
> > > same as the same progr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cédric Villemain a écrit :
> Joshua D. Drake a écrit :
>> On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
>>> Joshua D. Drake wrote:
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
>
>
KaiGai Kohei writes:
> Martijn van Oosterhout wrote:
>> On Mon, Feb 16, 2009 at 11:10:19AM +0900, KaiGai Kohei wrote:
>>> At the previous discussion, two items were pointed out.
>>>
>>> The one is called as covert channel. When a tuple with PK is refered by
>>> one or more tuples with FK, row-lev
On Monday 16 February 2009 12:06:55 Michael Meskes wrote:
> On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote:
> > Will a program built with ecpg 8.4 run against a 7.4 server work the
> > same as the same program built with ecpg 7.4 run against a 7.4 server?
> > (This implies that th
On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote:
> Will a program built with ecpg 8.4 run against a 7.4 server work the
> same as the same program built with ecpg 7.4 run against a 7.4 server?
> (This implies that the program uses only features present in 7.4.)
No, if the prog
Martijn van Oosterhout wrote:
> On Mon, Feb 16, 2009 at 11:10:19AM +0900, KaiGai Kohei wrote:
>> At the previous discussion, two items were pointed out.
>>
>> The one is called as covert channel. When a tuple with PK is refered by
>> one or more tuples with FK, row-level control prevents to update
59 matches
Mail list logo
