On Wed, 18 Jul 2007, Bruce Momjian wrote:
Oleg, Teodor,
I am confused by the following example. How does gin know to create a
tsvector, or does it? Does gist know too?
No, gist doesn't know. I don't remember why, Teodor ?
For GIN see http://archives.postgresql.org/pgsql-hackers/2007-05/msg
Oleg, Teodor,
I am confused by the following example. How does gin know to create a
tsvector, or does it? Does gist know too?
FYI, at some point we need to chat via instant messenger or IRC to
discuss the open items. My chat information is here:
http://momjian.us/main/contact.html
Oleg Bartunov wrote:
> On Wed, 18 Jul 2007, Bruce Momjian wrote:
>
> >
> >>> Why are we allowing my_filter_name here? Isn't that something for a
> >>> custom trigger. Is calling it tsearch() a good idea? Why not
> >>> tsvector_trigger().
> >>
> >> I don't see any benefit from the tsvector_trigg
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW, while I'm thinking of it --- it'd be real nice if the buildfarm
>> "configuration" printout included the flex and bison version numbers.
> Interestingly, none of our tools actually outputs the bison/flex
> versions - perhaps con
Tom Lane wrote:
BTW, while I'm thinking of it --- it'd be real nice if the buildfarm
"configuration" printout included the flex and bison version numbers.
Maybe gcc too (I know not every buildfarm member is compiling with gcc,
but it comes in enough different versions that this is likely to be
BTW, while I'm thinking of it --- it'd be real nice if the buildfarm
"configuration" printout included the flex and bison version numbers.
Maybe gcc too (I know not every buildfarm member is compiling with gcc,
but it comes in enough different versions that this is likely to be
useful info).
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I don't think we're ever going to fix things for the 7.3 error you're
> getting - please take it out of your rotation. 7.3 isn't quite as dead
> as Joshua suggested earlier, but it's certainly on life support.
I checked the CVS logs and it appears tha
Mark Wong wrote:
On 7/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
wombat long-standing configuration error (no Tk installed)
My apologies for not responding earlier. I see 7.3 contrib problems
for wombat but I don't see a config error for Tk with HEAD or any of
the other 8.x releases
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Oh, they're fully interchangeable at the wire level? Is this true both
> with respect to the PG client/backend protocol and the protocol to the
> authentication server?
I believe that's the case, yes.
> If there's no interoperability issues then I
> agree
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> Am I right in thinking that while the client<->postgres protocol may be the
> same the actual authentication tokens are different? That is, if you have a
> Windows Active Directory server then using SSPI will use your Windows
> credentials obtained from
"Mark Wong" <[EMAIL PROTECTED]> writes:
> On 7/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> wombat long-standing configuration error (no Tk installed)
> My apologies for not responding earlier. I see 7.3 contrib problems
> for wombat but I don't see a config error for Tk with HEAD or any
Magnus Hagander <[EMAIL PROTECTED]> writes:
> The issue is *not* about GSSAPI vs krb5. It's with GSSAPI vs SSPI.
> The wire protocol is the same for them. It's a matter of which *client
> library* should be used to produce the packets that go over the network.
Oh, they're fully interchangeable at
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>
>> The wire protocol is the same for them. It's a matter of which *client
>> library* should be used to produce the packets that go over the network.
>...
> On Windows, why would you need GSSAPI, if SSPI comes with the op
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote:
> Uh, this is really confusing. Let's see if I got this right. So we're
> talking about two orthogonal changes here:
It is kinda confusing. :)
> 1. Wire protocol. In 8.2 and below, we used the krb5 protocol. 8.3
> server and libpq will use the GSSAP
On 7/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
wombat long-standing configuration error (no Tk installed)
My apologies for not responding earlier. I see 7.3 contrib problems
for wombat but I don't see a config error for Tk with HEAD or any of
the other 8.x releases. I have the --with
Magnus Hagander wrote:
> Heikki Linnakangas wrote:
>> Stephen Frost wrote:
>>> Honestly, for now I'm happy w/ it being a connectionstring option. It
>>> seems the most appropriate place for it to go. That does mean that
>>> applications may need to be modified to support gssapi (where they might
Heikki Linnakangas wrote:
> Stephen Frost wrote:
>> Honestly, for now I'm happy w/ it being a connectionstring option. It
>> seems the most appropriate place for it to go. That does mean that
>> applications may need to be modified to support gssapi (where they might
>> not have to be for sspi si
On Wed, 18 Jul 2007, Bruce Momjian wrote:
Why are we allowing my_filter_name here? Isn't that something for a
custom trigger. Is calling it tsearch() a good idea? Why not
tsvector_trigger().
I don't see any benefit from the tsvector_trigger() name. If you want to add
some semantic, than t
Stephen Frost wrote:
> Honestly, for now I'm happy w/ it being a connectionstring option. It
> seems the most appropriate place for it to go. That does mean that
> applications may need to be modified to support gssapi (where they might
> not have to be for sspi since it's the default), but since
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Well, since you're the only one who've asked for the feature, I guess
> that's good enough for me unless someone else complains. If you have a
> good suggestion for a name for it, let me know, otherwise I'll just cook
> something up.
Mozilla uses 'gss
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> Stephen Frost wrote:
>>> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
Certainly not "just minor adjustments", since we need to do dynamic
loading and checking for the functions. That's the big one, which will
>>> If we
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
Oh, yea, and every place that uses Active Directory ..
Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
general.
I was referring to your first question, which, in my view, is the more
appropriate one *a
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> * Joshua D. Drake ([EMAIL PROTECTED]) wrote:
>>> How many people actually use kerberos... How many people who are using
>>> kerberos are going to be running 7.3. 7.3 is no longer supported so by
>>> postgresql.org so who cares
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > * Magnus Hagander ([EMAIL PROTECTED]) wrote:
> >> Certainly not "just minor adjustments", since we need to do dynamic
> >> loading and checking for the functions. That's the big one, which will
> >
> > If we're supporting krb5
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> No, no requirement. But you would certainly expect it to use it if you
> have SSL on the connection.
Uhh, perhaps, but my recollection is that it's generally *not* done that
way in other things.. Honestly, it doesn't matter to me, just wanted to
clea
Oleg Bartunov wrote:
> >> I agree, that there are could be more examples, but text search doesn't
> >> require something special !
> >> *Example* of trigger function is documented on
> >> http://momjian.us/expire/fulltext/HTML/textsearch-opfunc.html
> >
> > Yes, I see that in tsearch() here:
> >
>
On 7/18/07, Heikki Linnakangas <[EMAIL PROTECTED] > wrote:
Here's what I think we should do to the HOT patch:
I am all for simplifying the code. That would not only help us make it less
buggy but also improve its maintainability. But we would also need
to repeat the tests and run new tests t
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> Certainly not "just minor adjustments", since we need to do dynamic
>> loading and checking for the functions. That's the big one, which will
>
> If we're supporting krb5 anyway, and shipping the bits that go along
> with that,
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> The maintenance part of me suggesting getting rid of krb5 is the
>> smallest one. It being a non-standard protocol is more important, and
>> the fact that the exchange breaks the libpq protocol and is not
>> protected by SSL is
Just the SSPI piece.
Right now we run a mixture of PostgreSQL and SQL Server and the one
fustrating thing is that we have to have separate security architectures for
them. The SQL Server environment is nice because it allows SSPI and
eliminates the need to pass around passwords everywhere.
I
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Certainly not "just minor adjustments", since we need to do dynamic
> loading and checking for the functions. That's the big one, which will
If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loadi
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> The maintenance part of me suggesting getting rid of krb5 is the
> smallest one. It being a non-standard protocol is more important, and
> the fact that the exchange breaks the libpq protocol and is not
> protected by SSL is the big reason.
Erm, it do
Stephen Frost wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
This needs to be fixed.
>>> Non, GSSAPI and krb5 are *not* mutually exclusive.
>>> SSPI and GSSAPI are mutually exclusive.
>
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> But we're talking two different issues. Deprecating/removing krb5 is a
>> different thing from having GSSAPI and SSPI mutually exclusive or not.
>
> To the extent that keeping krb5 around implies a much lower burden on
> GSSAPI
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
>> OK, well thats a problem. pgAdmin supports back to 7.3...
>
> How many people actually use kerberos... How many people who are using
> kerberos are going to be running 7.3. 7.3 is no longer supported so by
> postgresql.org so who cares.
AOL, MIT, C
* Dave Page ([EMAIL PROTECTED]) wrote:
> Probably not in the majority of cases - but we have a large userbase these
> days, and a small percentage may still equate to a large number. I know at
> least two people that do use psqlODBC + Kerberos.
I certainly use it alot! Of course, we'll move to
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> But we're talking two different issues. Deprecating/removing krb5 is a
> different thing from having GSSAPI and SSPI mutually exclusive or not.
To the extent that keeping krb5 around implies a much lower burden on
GSSAPI support under Windows, I disag
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
> >> This needs to be fixed.
>
> > Non, GSSAPI and krb5 are *not* mutually exclusive.
>
> > SSPI and GSSAPI are mutually exclusive.
>
> Color me confu
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
>>> This needs to be fixed.
>
>> Non, GSSAPI and krb5 are *not* mutually exclusive.
>
>> SSPI and GSSAPI are mutually exclusive.
>
> Color me confused then. What's the diff
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The real problem in my mind is this business of the gssapi and krb5
> support being mutually exclusive.
Oh, I didn't catch that. That's wrong anyways, there could be multiple
applications on the same machine, some of which use krb4 and some which use
gss
Joshua D. Drake wrote:
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used
krb5 auth.
OK, well thats a problem. pgAdmin supports back
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
>> This needs to be fixed.
> Non, GSSAPI and krb5 are *not* mutually exclusive.
> SSPI and GSSAPI are mutually exclusive.
Color me confused then. What's the difference?
On Wed, 2007-07-18 at 11:41 +0100, Heikki Linnakangas wrote:
> I've done some experimenting on those items, producing several badly
> broken versions of the patch partly implementing those ideas. It looks
> like the patch size will go down from ~240 kB to ~210 kB, and more
> importantly, there wil
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tatsuo Ishii wrote:
> The conclusion of the discussion appears that we could reduce
> MAX_CONVERSION_GROWTH from 4 to
On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > But sure, we might leave it in there until there's a direct problem with it
> > (other than the ones we already know). Can I still get my deprecation of it
> > though? ;-)
>
> In the krb4 ca
[EMAIL PROTECTED] (Peter Eisentraut) writes:
> Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:
>> The main reasons would be to have less code to maintain,
>
> I don't think the krb5 support has needed all that much maintenance in the
> last few years.
>
>> and to make life
>> easier for
Magnus Hagander <[EMAIL PROTECTED]> writes:
> But sure, we might leave it in there until there's a direct problem with it
> (other than the ones we already know). Can I still get my deprecation of it
> though? ;-)
In the krb4 case, we left it in there until there was very little
probability anyone
Joshua D. Drake wrote:
pgAdmin was just one example. This prevents anyone with kerberos5 in a
similar situation upgrading their client libraries - including users
of the myriad of apps that use psqlODBC.
Who likely don't use kerberos.
Probably not in the majority of cases - but we have a lar
Dave Page wrote:
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used
krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think y
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
How many people actually use kerberos... How many peop
Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:
> The main reasons would be to have less code to maintain,
I don't think the krb5 support has needed all that much maintenance in the
last few years.
> and to make life
> easier for packagers. For example, win32 would no longer need to s
On Tue, 17 Jul 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
On Tue, 17 Jul 2007, Bruce Momjian wrote:
I think the tsearch documentation is nearing completion:
http://momjian.us/expire/fulltext/HTML/textsearch.html
but I am not happy with how tsearch is enabled in a user table:
Just an observation, but when we cluster (or any other time we rebuild a heap)
we are creating a useless record type and array type for the temporary heap we
use which is subsequently dropped.
postgres=# cluster;
DEBUG: drop auto-cascades to type pg_temp_16474
DEBUG: drop auto-cascades to type
Andrew Dunstan wrote:
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think you need to put for
Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5
auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
I think you need to put forward an alternative pla
On Wed, Jul 18, 2007 at 12:26:28PM +0100, Heikki Linnakangas wrote:
> Magnus Hagander wrote:
> > But sure, we might leave it in there until there's a direct problem with it
> > (other than the ones we already know). Can I still get my deprecation of it
> > though? ;-)
>
> I'm not sure what the dep
Magnus Hagander wrote:
> But sure, we might leave it in there until there's a direct problem with it
> (other than the ones we already know). Can I still get my deprecation of it
> though? ;-)
I'm not sure what the deprecation would mean in the client-side. You're
going to need it if you want to c
On Wed, Jul 18, 2007 at 12:16:49PM +0100, Heikki Linnakangas wrote:
> Magnus Hagander wrote:
> > On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
> >> Magnus Hagander wrote:
> libpq would still work against older server versions, right?
> >>> Not once krb5 is removed. Assuming the ol
Magnus Hagander wrote:
> On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
>> Magnus Hagander wrote:
libpq would still work against older server versions, right?
>>> Not once krb5 is removed. Assuming the older server version used krb5 auth.
>> OK, well thats a problem. pgAdmin suppor
Magnus Hagander wrote:
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to
On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:
> Magnus Hagander wrote:
> >>libpq would still work against older server versions, right?
> >
> >Not once krb5 is removed. Assuming the older server version used krb5 auth.
>
> OK, well thats a problem. pgAdmin supports back to 7.3...
You
Magnus Hagander wrote:
libpq would still work against older server versions, right?
Not once krb5 is removed. Assuming the older server version used krb5 auth.
OK, well thats a problem. pgAdmin supports back to 7.3...
/D
---(end of broadcast)-
On Wed, Jul 18, 2007 at 11:45:19AM +0100, Heikki Linnakangas wrote:
> Magnus Hagander wrote:
> > Now that we have working GSSAPI authentication, I'd like to see the
> > following done:
> >
> > * Deprecate krb5 authentication in 8.3. At least in documentation, possibly
> > with a warning when loadi
Magnus Hagander wrote:
> Now that we have working GSSAPI authentication, I'd like to see the
> following done:
>
> * Deprecate krb5 authentication in 8.3. At least in documentation, possibly
> with a warning when loading pg_hba.conf?
> * Remove krb5 authenticatino completely in 8.4.
libpq would s
Here's what I think we should do to the HOT patch:
1. Get rid of row-level fragmentation and handling dealing with
LP_DELETEd line pointers. Instead, take a vacuum lock opportunistically,
and defrag pages using the normal PageRepairFragmentation function. I'm
not sure where exactly we would do the
On Tue, Jul 17, 2007 at 11:00:35AM -0700, Paul Silveira wrote:
>
> This is great. I've worked on 2 projects in the last year that desperately
> needed this. It will certainly make the security model more seamless...
Thanks for letting us know.
Are you interested in just the SSPI parts, or also
Now that we have working GSSAPI authentication, I'd like to see the
following done:
* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.
The reasons for this is:
* krb5 auth doesn't do
On Wed, Jul 18, 2007 at 09:44:02AM +0100, Dave Page wrote:
> Magnus Hagander wrote:
> > Dave Page wrote:
> >> Magnus Hagander wrote:
> >>> So what we'd need in that case is a new libpq connectionstring
> >>> parameter. Which can be done, but it'd require that all frontends that
> >>> use libpq add
The conclusion of the discussion appears that we could reduce
MAX_CONVERSION_GROWTH from 4 to 3 safely with all existing built-in
conversions.
However, since user defined conversions could set arbitrary growth
rate, probably it would be better leave it as it is now.
For 8.4, maybe we could change
Sorry for dealy.
> On Tue, May 29, 2007 20:51, Tatsuo Ishii wrote:
>
> > Thinking more, it striked me that users can define arbitarily growing
> > rate by using CFREATE CONVERSION. So it seems we need functionality to
> > define the growing rate anyway.
>
> Would it make sense to define just the
On Wed, 2007-07-18 at 01:01 +0100, Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Where are we on this?
>
> Well Simon just sent the reworked patch yesterday so the answer is we haven't
> started tuning this parameter. (Bruce's message is referring to the discussion
> ab
Magnus Hagander wrote:
> Dave Page wrote:
>> Magnus Hagander wrote:
>>> So what we'd need in that case is a new libpq connectionstring
>>> parameter. Which can be done, but it'd require that all frontends that
>>> use libpq add support for it - such as pgadmin. I'm not sure if the ODBC
>>> driver w
73 matches
Mail list logo
