Re: [HACKERS] More flexible LDAP auth search filters?

[Mark Cave-Ayland]

On 17/07/17 00:14, Stephen Frost wrote:

>> If it helps, we normally recommend that clients use ldaps for both AD
>> and UNIX environments, although this can be trickier from an
>> administrative perspective in AD environments because it can require
>> changes to the Windows firewall and certificate installation.
> 
> LDAPS is better than straight LDAP, of course, but it still doesn't
> address the issue that the password is sent to the server, which both
> SCRAM and Kerberos do and is why AD environments use Kerberos for
> authentication, and why everything in an AD environment also should use
> Kerberos.
> 
> Using Kerberos should also avoid the need to hack the Windows firewall
> or deal with certificate installation.  In an AD environment, it's
> actually pretty straight-forward to add a PG server too.  Further, in my
> experience at least, there's been other changes recommended by Microsoft
> that prevent using LDAP for auth because it's insecure.

Oh sure - I'm not questioning that Kerberos is a far better choice in
pure AD environments, it's just that I spend the majority of my time in
mixed-mode environments where Windows is very much in the minority.

In my experience LDAP is often implemented badly; for example the
majority of software still uses simple binds (i.e. plain logins) rather
than using SASL binds which support a whole range of better
authentication methods (e.g. GSSAPI, and even DIGEST-MD5 has been
mandatory for v3 and is implemented on AD).

And yes, while better authentication mechanisms do exist, I find that
all too often most software packages claim LDAP support rather than
Kerberos, and even then it is often limited to LDAP simple binds without
ldaps support.


ATB,

Mark.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] segfault in HEAD when too many nested functions call

[Noah Misch]

On Sat, Jul 15, 2017 at 11:22:37AM -0400, Tom Lane wrote:
> Julien Rouhaud  writes:
> > Since b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 (Andres in Cc), if you
> > write queries which result in infinite recursion (or just too many
> > nested function calls), execution ends with segfault instead of intended
> > exhausted max_stack_depth:
> 
> Yes.  We discussed this before the patch went in [1].  I wanted to put
> a stack depth check in ExecProcNode(), and still do.  Andres demurred,
> claiming that that was too much overhead, but didn't really provide a
> credible alternative.  The thread drifted off without any resolution,
> but clearly we need to do something before 10.0 final.

[Action required within three days.  This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item.  Andres,
since you committed the patch believed to have created it, you own this open
item.  If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know.  Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message.  Include a date for your subsequent status update.  Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10.  Consequently, I will appreciate your efforts
toward speedy resolution.  Thanks.

[1] 
https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More flexible LDAP auth search filters?

[Stephen Frost]

Magnus,

* Magnus Hagander (mag...@hagander.net) wrote:
> On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost  wrote:
> > I'd suggest that we try to understand why Kerberos couldn't be used in
> > that environment.  I suspect in at least some cases what users would
> > like is the ability to do Kerberos auth but then have LDAP checked to
> > see if a given user (who has now auth'd through Kerberos) is allowed to
> > connect.  We don't currently have any way to do that, but if we were
> > looking for things to do, that's what I'd suggest working on rather than
> > adding more to our LDAP auth system and implying by doing so that it's
> > reasonable to use.
> >
> > I find it particularly disappointing to see recommendations for using
> > LDAP auth, particularly in AD environments, that don't even mention
> > Kerberos or bother to explain how using LDAP sends the user's PW to the
> > server in cleartext.
> 
> You do realize, I'm sure, that there are many LDAP servers out there that
> are not AD, and that do not come with a Kerberos server attached to them...

I am aware that some exist, I've even contributed to their development
and packaging, but that doesn't make it a good idea to use them for
authentication.

> I agree that Kerberos is usually the better choice *if it's available*.

Which is the case in an AD environment..

> It's several orders of magnitude more complicated to set up though, and
> there are many environments that have ldap but don't have Kerberos.

Frankly, I simply don't agree with this.

> Refusing to improve LDAP for the users who have no choice seems like a very
> unfriendly thing to do.

I'm fine with improving LDAP in general, but, as I tried to point out,
having a way to make it easier to integrate PG into an AD environment
would be better.  It's not my intent to stop this patch but rather to
point out the issues with LDAP auth that far too frequently are not
properly understood.

> (And you can actually reasonably solve the case of
> kerberos-for-auth-ldap-for-priv by syncing the groups into postgres roles)

Yes, but sync'ing roles is a bit of a pain and it'd be nice if we could
avoid it, or perhaps make it easier.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] More flexible LDAP auth search filters?

[Stephen Frost]

Mark,

* Mark Cave-Ayland (mark.cave-ayl...@ilande.co.uk) wrote:
> On 16/07/17 23:26, Thomas Munro wrote:
> > Thank you very much for this feedback and example, which I used in the
> > documentation in the patch.  I see similar examples in the
> > documentation for other things on the web.
> > 
> > I'll leave it up to Magnus and Stephen to duke it out over whether we
> > want to encourage LDAP usage, extend documentation to warn about
> > cleartext passwords with certain LDAP implementations or
> > configurations, etc etc.  I'll add this patch to the commitfest and
> > get some popcorn.
> 
> If it helps, we normally recommend that clients use ldaps for both AD
> and UNIX environments, although this can be trickier from an
> administrative perspective in AD environments because it can require
> changes to the Windows firewall and certificate installation.

LDAPS is better than straight LDAP, of course, but it still doesn't
address the issue that the password is sent to the server, which both
SCRAM and Kerberos do and is why AD environments use Kerberos for
authentication, and why everything in an AD environment also should use
Kerberos.

Using Kerberos should also avoid the need to hack the Windows firewall
or deal with certificate installation.  In an AD environment, it's
actually pretty straight-forward to add a PG server too.  Further, in my
experience at least, there's been other changes recommended by Microsoft
that prevent using LDAP for auth because it's insecure.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] More flexible LDAP auth search filters?

[Thomas Munro]

On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro
 wrote:
> ldap-search-filters-v2.patch

Gah, it would help if I could spell "occurrences" correctly.  Fixed in
the attached.

-- 
Thomas Munro
http://www.enterprisedb.com


ldap-search-filters-v3.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More flexible LDAP auth search filters?

[Mark Cave-Ayland]

On 16/07/17 23:26, Thomas Munro wrote:

> Thank you very much for this feedback and example, which I used in the
> documentation in the patch.  I see similar examples in the
> documentation for other things on the web.
> 
> I'll leave it up to Magnus and Stephen to duke it out over whether we
> want to encourage LDAP usage, extend documentation to warn about
> cleartext passwords with certain LDAP implementations or
> configurations, etc etc.  I'll add this patch to the commitfest and
> get some popcorn.

If it helps, we normally recommend that clients use ldaps for both AD
and UNIX environments, although this can be trickier from an
administrative perspective in AD environments because it can require
changes to the Windows firewall and certificate installation.

Whilst OpenLDAP will support ldap+starttls you can end up with some
clients with starttls either disabled or misconfigured sending plaintext
passwords over the wire regardless, so it's generally easiest to
firewall ldap port 389 at the edge of the trusted VLAN so that only
ldaps port 636 connections make it out onto the untrusted network
hosting the local AD/OpenLDAP server.


ATB,

Mark.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More flexible LDAP auth search filters?

[Thomas Munro]

On Mon, Jul 17, 2017 at 5:58 AM, Mark Cave-Ayland
 wrote:
>> Any other views from LDAP-users?
>
> I've spent quite a bit of time integrating various bits of
> non-PostgreSQL software to LDAP and in my experience option 3 tends to
> be the standard.
>
> Generally you find that you will be given the option to set the
> attribute for the default search filter of the form
> "(attribute=username)" which defaults to uid for UNIX-type systems and
> sAMAccountName for AD. However there is always the ability to specify a
> custom filter where the user is substituted via e.g. %u to cover all the
> other use-cases.

Cool.  Here is a new version of the patch updated to do it exactly
like that.  I tested it against OpenLDAP.

> As an example, I don't know if anyone would actually do this with
> PostgreSQL but I've been asked on multiple occasions to configure
> software so that users should be allowed to log in with either their
> email address or username which is easily done with a custom LDAP filter
> like "(|(mail=%u)(uid=%u))".

Thank you very much for this feedback and example, which I used in the
documentation in the patch.  I see similar examples in the
documentation for other things on the web.

I'll leave it up to Magnus and Stephen to duke it out over whether we
want to encourage LDAP usage, extend documentation to warn about
cleartext passwords with certain LDAP implementations or
configurations, etc etc.  I'll add this patch to the commitfest and
get some popcorn.

-- 
Thomas Munro
http://www.enterprisedb.com


ldap-search-filters-v2.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More flexible LDAP auth search filters?

[Magnus Hagander]

On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost  wrote:

> Magnus, all,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > (FWIW, a workaround I've applied more than once to this in AD
> environments
> > (where kerberos for one reason or other can't be done, sorry Stephen) is
> to
> > set up a RADIUS server and use that one as a "middle man". But it would
> be
> > much better if we could do it natively)
>
> I'd suggest that we try to understand why Kerberos couldn't be used in
> that environment.  I suspect in at least some cases what users would
> like is the ability to do Kerberos auth but then have LDAP checked to
> see if a given user (who has now auth'd through Kerberos) is allowed to
> connect.  We don't currently have any way to do that, but if we were
> looking for things to do, that's what I'd suggest working on rather than
> adding more to our LDAP auth system and implying by doing so that it's
> reasonable to use.
>
> I find it particularly disappointing to see recommendations for using
> LDAP auth, particularly in AD environments, that don't even mention
> Kerberos or bother to explain how using LDAP sends the user's PW to the
> server in cleartext.
>

You do realize, I'm sure, that there are many LDAP servers out there that
are not AD, and that do not come with a Kerberos server attached to them...

I agree that Kerberos is usually the better choice *if it's available*.
It's several orders of magnitude more complicated to set up though, and
there are many environments that have ldap but don't have Kerberos.

Refusing to improve LDAP for the users who have no choice seems like a very
unfriendly thing to do.

(And you can actually reasonably solve the case of
kerberos-for-auth-ldap-for-priv by syncing the groups into postgres roles)

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: [HACKERS] More flexible LDAP auth search filters?

[Stephen Frost]

Magnus, all,

* Magnus Hagander (mag...@hagander.net) wrote:
> (FWIW, a workaround I've applied more than once to this in AD environments
> (where kerberos for one reason or other can't be done, sorry Stephen) is to
> set up a RADIUS server and use that one as a "middle man". But it would be
> much better if we could do it natively)

I'd suggest that we try to understand why Kerberos couldn't be used in
that environment.  I suspect in at least some cases what users would
like is the ability to do Kerberos auth but then have LDAP checked to
see if a given user (who has now auth'd through Kerberos) is allowed to
connect.  We don't currently have any way to do that, but if we were
looking for things to do, that's what I'd suggest working on rather than
adding more to our LDAP auth system and implying by doing so that it's
reasonable to use.

I find it particularly disappointing to see recommendations for using
LDAP auth, particularly in AD environments, that don't even mention
Kerberos or bother to explain how using LDAP sends the user's PW to the
server in cleartext.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

[Greg Stark]

On 15 July 2017 at 23:00, Tom Lane  wrote:

> While it's too late in the v10 cycle to do anything very meaningful
> about this now, I am tempted to strengthen the deprecation notice's
> wording from "might disappear" to "will disappear".

"Will certainly disappear at some unspecified date" is a lot less
convincing than "will disappear in 2021 in Postgres 14". The specific
year and version number is irrelevant
but picking and naming a specific one makes it a lot easier to follow
through come that date.


-- 
greg


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More flexible LDAP auth search filters?

[Mark Cave-Ayland]

On 16/07/17 00:08, Thomas Munro wrote:

> On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander  wrote:
>> On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro
>>  wrote:
>>> A post on planet.postgresql.org today reminded me that a colleague had
>>> asked me to post this POC patch here for discussion.  It allows custom
>>> filters with ldapsearchprefix and ldapsearchsuffix.  Another approach
>>> might be to take a filter pattern with "%USERNAME%" or whatever in it.
>>> There's an existing precedent for the prefix and suffix approach, but
>>> on the other hand a pattern approach would allow filters where the
>>> username is inserted more than once.
>>
>>
>> Do we even need prefix/suffix? If we just make it "ldapsearchpattern", then
>> you could have something like:
>>
>> ldapsearchattribute="uid"
>> ldapsearchfilter="|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA Team)"
>>
>> We could then always to substitution of the kind:
>> (&(attr=)())
>>
>> which would in this case give:
>> (&(uid=mha)(|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA Team)))
>>
>>
>> Basically we'd always AND together the username lookup with the additional
>> filter.
> 
> Ok, so we have 3 ideas put forward:
> 
> 1.  Wrap username with ldapsearchprefix ldapsearchsuffix to build
> filter (as implemented by POC patch)
> 2.  Optionally AND ldapsearchfilter with the existing
> ldapsearchattribute-based filter (Magnus's proposal)
> 3.  Pattern-based ldapsearchfilter so that %USER% is replaced with
> username (my other suggestion)
> 
> The main argument for approach 1 is that it follows the style of the
> bind-only mode.
> 
> With idea 2, I wonder if there are some more general kinds of things
> that people might want to do that that wouldn't be possible because it
> has to include (attribute=user)... perhaps something involving a
> substring or other transformation functions (but I'm no LDAP expert,
> that may not make sense).
> 
> With idea 3 it would allow "(|(foo=%USER%)(bar=%USER%))", though I
> don't know if any such multiple-mention filters would ever make sense
> in a sane LDAP configuration.
> 
> Any other views from LDAP-users?

I've spent quite a bit of time integrating various bits of
non-PostgreSQL software to LDAP and in my experience option 3 tends to
be the standard.

Generally you find that you will be given the option to set the
attribute for the default search filter of the form
"(attribute=username)" which defaults to uid for UNIX-type systems and
sAMAccountName for AD. However there is always the ability to specify a
custom filter where the user is substituted via e.g. %u to cover all the
other use-cases.

As an example, I don't know if anyone would actually do this with
PostgreSQL but I've been asked on multiple occasions to configure
software so that users should be allowed to log in with either their
email address or username which is easily done with a custom LDAP filter
like "(|(mail=%u)(uid=%u))".


ATB,

Mark.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] [GSOC][weekly report 6] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

[Mengxing Liu]

In the last week:
   1) I tried to find out what's wrong with my last patch: reducing the 
contention on SerializableFinishedListLock. 
   2) I used a skip list to replace the linked list to speedup conflict 
tracking. But there are still some bugs resulting in segment fault. 
   Here is the code: 
https://github.com/liumx10/postgresql/commit/c469e14e27c31edba5caff001647440040f53c84
   I will figure it out in the next days.


Here is the details.
1) Reducing the contention on SerializableFinishedListLock
In the last email, I reported that reducing the contention on FinishedListLock 
didn't increase the performance. The system became even 
slower in some cases. I thought the key point was not the problem of my codes. 
The original Pseudo code looks like this:
 
 lockAcquire(SerializableFinishedListLock)
 for  predlock in this Sxact:
lockAcquire(patitionlock);
   // do something;
unlock(paritionlock);
 releaseAcquire(SerializableFinishedListLock)


SerializableFinishedListLock likes a coarse-grained lock, while partition locks 
like fine-grained lock. My patch essentially remove the outer lock.
But unfortunately, there are many other places requiring partition locks. We 
have only 16 partition locks in all. 
So even without SerializableFinishedListLock, contentions will happen on 
partition locks. The performance wouldn't be improved. 


Why the performance became worse in some cases? Context switch may be one of 
the reason. 
It was easier to fail on getting locks when using fine-grained locks,
which would hang the current process and result in a context switch.
For example, if it failed to get partition locks 5 times in a for loop, there 
would be 5 context switch at least.
I used vmstat to count the context switch. In the benchmark where my patch had 
a worse performance, there were more context switch happened than using the 
original code. 
I also modify the source code to count where requiring partition locks failed. 
In the original version, only a few (no more than 1%) locking failure came from 
the pseudo code above. 
But in my patch, more than 50% failure came from this part. 


2) Skip list
To make it simple, I didn't develop an independent data structure for skip 
list. Instead, I used two linked list to simulate skip list. 
Most transactions have no more than 50 conflicts, so two level skip list is 
enough now. 
I'll make a clean patch after I figure out bugs. 


--

Sincerely


Mengxing Liu

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

[Tom Lane]

Robert Haas  writes:
> On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane  wrote:
>> * contrib/spi/timetravel depends on abstime columns to represent what
>> would nowadays be better done as a tstzrange.  I'd have thought we
>> could maybe toss that example module overboard, but we just today got
>> a question about its usage, so I'm afraid it's not quite dead yet.
>> What shall we do with that?

> No idea.  I think if nobody's willing to come up with a plan for this
> and do the work to implement it, we should just remove the module when
> we get closer to 2038.  But I don't think we have to make that
> decision for at least another 5 years or so.

The plan I'd tentatively suggest is to just s/abstime/timestamptz/g
in the timetravel module, something that would be unlikely to take more
than an hour's work.  If anyone was actually using it in production
they'd have to do some ALTER COLUMN TYPE changes before the trigger
would work again ... but that would get forced on them eventually
anyway.  Yup, you could turn this molehill into a mountain of work
if you wanted to have a more friendly transition, but I don't see
anyone putting in that much effort.

>> While it's too late in the v10 cycle to do anything very meaningful
>> about this now, I am tempted to strengthen the deprecation notice's
>> wording from "might disappear" to "will disappear".

> -1 for changing that; such predictions often turn out to be wrong.

Those types will definitely fail for all use-cases in 2038, and for
many use-cases significantly before that; there's no uncertainty in that
prediction.  The only way they aren't going to disappear before 2038 is
if the project is defunct first, or if somebody is sufficiently concerned
with having an easier migration path that they are willing to design and
implement one.  I don't believe any of the usual suspects are going to do
that.  But if there's somebody who would care enough to de-lurk and make
it happen, they'd be much more likely to do so soon enough if there's some
advance warning in the docs.  Or in other words, I don't want to go from
"might disappear" in vN to gone in vN+1 with no intermediate state.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

[Robert Haas]

On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane  wrote:
> Right offhand, I don't think there is any functionality in these
> types that isn't handled as well or better by timestamptz, interval,
> and tstzrange respectively.  And they're basically undocumented
> except for a sort-of deprecation notice just above section 8.5.1.
> So my inclination is to remove them rather than try to upgrade them
> in any way.  However, we'd have to do something about:
>
> * The legacy system views pg_shadow and pg_user have abstime columns.
> Experimentation suggests that we could convert those to timestamptz(0)
> and the output format wouldn't change, so maybe that's a good enough
> fix there.

+1 for doing that in v11.

> * contrib/spi/timetravel depends on abstime columns to represent what
> would nowadays be better done as a tstzrange.  I'd have thought we
> could maybe toss that example module overboard, but we just today got
> a question about its usage, so I'm afraid it's not quite dead yet.
> What shall we do with that?

No idea.  I think if nobody's willing to come up with a plan for this
and do the work to implement it, we should just remove the module when
we get closer to 2038.  But I don't think we have to make that
decision for at least another 5 years or so.

> While it's too late in the v10 cycle to do anything very meaningful
> about this now, I am tempted to strengthen the deprecation notice's
> wording from "might disappear" to "will disappear".

-1 for changing that; such predictions often turn out to be wrong.

> And it's not good
> that the documentation of contrib/spi/timetravel contains nothing
> whatever pointing out the lack of future-proof-ness of abstime.

+1 for fixing that, though.  Maybe we can find a wording that says in
effect "this module will need to be removed or fixed sometime not too
many years from now; if you care about keeping it around, maybe you
should volunteer to do the necessary fixing".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More flexible LDAP auth search filters?

[Magnus Hagander]

On Sun, Jul 16, 2017 at 1:08 AM, Thomas Munro  wrote:

> On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander 
> wrote:
> > On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro
> >  wrote:
> >> A post on planet.postgresql.org today reminded me that a colleague had
> >> asked me to post this POC patch here for discussion.  It allows custom
> >> filters with ldapsearchprefix and ldapsearchsuffix.  Another approach
> >> might be to take a filter pattern with "%USERNAME%" or whatever in it.
> >> There's an existing precedent for the prefix and suffix approach, but
> >> on the other hand a pattern approach would allow filters where the
> >> username is inserted more than once.
> >
> >
> > Do we even need prefix/suffix? If we just make it "ldapsearchpattern",
> then
> > you could have something like:
> >
> > ldapsearchattribute="uid"
> > ldapsearchfilter="|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA
> Team)"
> >
> > We could then always to substitution of the kind:
> > (&(attr=)())
> >
> > which would in this case give:
> > (&(uid=mha)(|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA Team)))
> >
> >
> > Basically we'd always AND together the username lookup with the
> additional
> > filter.
>
> Ok, so we have 3 ideas put forward:
>
> 1.  Wrap username with ldapsearchprefix ldapsearchsuffix to build
> filter (as implemented by POC patch)
> 2.  Optionally AND ldapsearchfilter with the existing
> ldapsearchattribute-based filter (Magnus's proposal)
> 3.  Pattern-based ldapsearchfilter so that %USER% is replaced with
> username (my other suggestion)
>
> The main argument for approach 1 is that it follows the style of the
> bind-only mode.
>

Agreed, but I'm not sure it's a good style to follow (and yes, I think I
may be the original author of it..). I'd rank option 3 over option 1.


>
> With idea 2, I wonder if there are some more general kinds of things
> that people might want to do that that wouldn't be possible because it
> has to include (attribute=user)... perhaps something involving a
> substring or other transformation functions (but I'm no LDAP expert,
> that may not make sense).
>

Yeah, that's exactly what I'm wondering about it :)



>
> With idea 3 it would allow "(|(foo=%USER%)(bar=%USER%))", though I
> don't know if any such multiple-mention filters would ever make sense
> in a sane LDAP configuration.
>
> Any other views from LDAP-users?
>
>

+1 for some input from people who directly use it in larger LDAP
environments. If we're going to change how it works, let's make it right
this time!

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: [HACKERS] Multi column range partition table

[Dean Rasheed]

On 14 July 2017 at 06:12, Robert Haas  wrote:
> I agree that it's a big problem that (10, UNBOUNDED)
> interpreted as a maximum value means first_column <= 10 and when
> interpreted as a minimum value means first_column >= 10, because those
> things aren't opposites of each other.  I guess the proposal here
> would make (10, MAXVALUE) as a maximum value mean first_column <= 10
> and as a minimum would mean first_column > 10, and contrariwise for
> MINVALUE.  That seems to restore the intended design principle of the
> system, which is good

Right. So in general, when using MINVALUE/MAXVALUE for the 2nd column
of a 2-column partitioning scheme, the partition constraints simplify
as follows:

  FROM (x, MINVALUE) => col1 >= x
  FROM (x, MAXVALUE) => col1 > x

  TO (x, MINVALUE)   => col1 < x
  TO (x, MAXVALUE)   => col1 <= x

which restores the property that one partition can be made contiguous
with another by having the upper bounds of one partition equal to the
lower bounds of the other.

Note that the choice of MINVALUE or MAXVALUE only affects whether the
constraint on the previous column is inclusive or exclusive. That's
quite different from what an INCLUSIVE/EXCLUSIVE flag would do.


>, but...
>
> ...originally, Amit proposed to attach a postfix INCLUSIVE or
> EXCLUSIVE to each bound specification, and this does feel like a bit
> of a back door to the same place, kinda.  A partition defined to run
> from (10, MAXVALUE) TO (11, MAXVALUE) is a lot like a partition
> defined to run from (10) EXCLUSIVE to (11) EXCLUSIVE.  And if we
> eventually decide to allow that, then what will be the difference
> between a partition which starts at (10, MAXVALUE) EXCLUSIVE and one
> which starts from (10, MAXVALUE) INCLUSIVE?

The INCLUSIVE/EXCLUSIVE flag would apply to the constraint as a whole:

  FROM (x, y) INCLUSIVE => (col1, col2) >= (x, y)
  FROM (x, y) EXCLUSIVE => (col1, col2) > (x, y)

  TO (x, y) INCLUSIVE   => (col1, col2) <= (x, y)
  TO (x, y) EXCLUSIVE   => (col1, col2) < (x, y)

which, when expanded out, actually only affects the constraint on the
final column, and then only in the case where all the other columns
are equal to the partition bound value:

  FROM (x, y) INCLUSIVE => col1 > x OR (col1 = x AND col2 >= y)
  FROM (x, y) EXCLUSIVE => col1 > x OR (col1 = x AND col2 > y)

  TO (x, y) INCLUSIVE   => col1 < x OR (col2 = x AND col2 <= y)
  TO (x, y) EXCLUSIVE   => col1 < x OR (col2 = x AND col2 < y)

So while MINVALUE/MAXVALUE makes a particular column unbounded
below/above, and as a side-effect can influence the inclusivity of the
preceding column, INCLUSIVE/EXCLUSIVE affects the inclusivity of the
final column (something that MINVALUE/MAXVALUE cannot do).

MINVALUE/MAXVALUE takes precedence, in the sense that if the bound on
any column is MINVALUE/MAXVALUE, that column and any later columns are
unbounded and no longer appear in the partition constraint expression,
and so any INCLUSIVE/EXCLUSIVE flag would have no effect. That seems
pretty intuitive to me -- "unbounded inclusive" is no different from
"unbounded exclusive".

Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can
also be done using using MINVALUE/MAXVALUE, by artificially adding
another partitioning column and making it unbounded above/below, but
that would really just be a hack, and it (artificially adding an extra
column) would be unnecessary if we added INCLUSIVE/EXCLUSIVE support
in a later release. Thus, I think the 2 features would complement each
other quite nicely.

Regards,
Dean


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers