I built an index on a jsonb column of a table with RLS enabled but it
was not being used. Turns out the the function jsonb_contains needed
to be LEAKPROOF (thanks Joe Conway). However I do not actually know if
jsonb_contains is LEAKPROOF. Who's responsibility is it to insure
functions are leakproof
NEC Business Creation Division / PG-Strom Project
> KaiGai Kohei
>
>
>> -Original Message-
>> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ted Toth
>> Sent: Wednesday, July 15, 2015 2:59 AM
>> To: Kohei KaiGai
So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?
Ted
On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai wrote:
> 2015-07-15 2:39 GMT+09:00 Ted Toth :
>&g
That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.
Ted
On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas wrote:
> On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth wrote:
>> I'm sort of
I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?
Ted
On Tue, Jul 14, 2015 at 12:09 PM, Adam Brightw
Are there any other packagers following the Fedora 'standards' that
you are aware of?
On Wed, May 27, 2015 at 2:40 PM, Robert Haas wrote:
> On Wed, May 27, 2015 at 3:25 PM, Ted Toth wrote:
>> On Wed, May 27, 2015 at 1:31 PM, Robert Haas wrote:
>>> On Wed, May 27
http://yum.postgresql.org/9.4/redhat/rhel-6.5-x86_64/
On Wed, May 27, 2015 at 1:31 PM, Robert Haas wrote:
> On Wed, May 27, 2015 at 11:35 AM, Ted Toth wrote:
>> I'm trying to use a newer version than is available from RH in our
>> custom distro but am having problems ins
I'm trying to use a newer version than is available from RH in our
custom distro but am having problems install both x86_64 and i686 rpms
because file conflicts. We have some i686 packages that use libgdal
which pulls in libpq which ends up in the same location in both the
x86_64 and i686 postgresq