headers
Bruce Momjian | 1 Jun 2003 05:52
Picon

Re: compile error on cvs tip

Sean Chittenden wrote:
> > > auth.c: In function `pg_krb5_recvauth':
> > > auth.c:294: structure has no member named `user'
> > 
> > Ooops, my fault --- I didn't build with Kerberos support after
> > changing those field names.
> > 
> > Now that I think about it, there might be similar omissions in the
> > PAM or Kerberos4 support --- can anyone try those?
> 
> krb4 code should be removed from PostgreSQL ASAP for various
> insecurities in the protocol.  It's been removed from FreeBSD, MIT,
> and Heimdal's code base and is officially unsupported as of June this
> year.  -sc

Did we decide we _didn't_ want to remove krb4?  Removal seems like a
good idea to me, but I am just checking if the consensus was to keep it.
I think someone said it was OK in a closed environment or something. 
Maybe we need to document that it is not recommended.

--

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman <at> candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo <at> postgresql.org)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bruce Momjian | 1 Jun 2003 06:14
Picon

Re: Please, apply patch for current CVS


Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Teodor Sigaev wrote:
> Patch for contrib/intarray and contrib/ltree modules.
> 
> Download from: 
> http://www.sai.msu.su/~megera/postgres/gist/patches/intarray_ltree.patch.gz
> 
> Changes:
> 1 intarray: bugfix for int[]-int[] operation
> 2 intarray: split _int.c to several files (_int.c now is unused)
> 3 ntarray (gist__intbig_ops opclass): use special type for index storage
> 4 ltree (gist__ltree_ops opclass), intarray (gist__intbig_ops): optimize GiST's 
> penalty and picksplit interface functions, now use Hemming distance.
> 
> Thank you.
> 
> -- 
> Teodor Sigaev                                  E-mail: teodor <at> sigaev.ru
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Momjian | 1 Jun 2003 06:09
Picon

Re: How about an am_superuser GUC parameter (non-settable)?

Tom Lane wrote:
> Peter Eisentraut <peter_e <at> gmx.net> writes:
> > I'm a little uneasy with puttting too much extra burden on the GUC
> > mechanism, which is after all a system to configure the server, not to
> > retrieve or communicate data.  Even the "server_version" thing recently
> > added doesn't make me happy.  If an application wants to know that, it
> > should send a query.
> 
> Well, I think there is a very demonstrable reason to send the server
> version as part of the startup protocol: "send a query" isn't a
> trustworthy way for an application to find that out, given the rate at
> which we are changing the server.  For example, the fully correct way
> to do that in 7.3 is "select pg_catalog.version()", but this syntax
> doesn't work at all in pre-7.3 servers.  And that doesn't even consider
> the autocommit issue...
> 
> If GUC didn't exist then a green-field design for sending the server
> version during startup would doubtless have looked different.  But we
> have the mechanism, it performs excellently, and extending it in this
> particular direction seems like a very reasonable design choice to me.
> You know not how well you wrought ;-)

I don't see this implemented yet.  I know Peter didn't like it, but I
saw no other objections.  Is it a TODO item?

--

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman <at> candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Momjian | 1 Jun 2003 06:31
Picon

Re: "Adding missing from clause"


Added to TODO:

	* Add config variable to prevent auto-adding missing FROM-clause
	  tables

---------------------------------------------------------------------------

Philip Warner wrote:
> At 02:36 PM 29/04/2003 -0700, Josh Berkus wrote:
> >I'd far rather have a fatal query error than have Postgres
> >automatically insert the tables it thinks I wanted
> 
> I too would dearly like to see this.
> 
> 
> ----------------------------------------------------------------
> Philip Warner                    |     __---_____
> Albatross Consulting Pty. Ltd.   |----/       -  \
> (A.B.N. 75 008 659 498)          |          /( <at> )   ______---_
> Tel: (+61) 0500 83 82 81         |                 _________  \
> Fax: (+61) 03 5330 3172          |                 ___________ |
> Http://www.rhyme.com.au          |                /           \|
>                                   |    --________--
> PGP key available upon request,  |  /
> and from pgp5.ai.mit.edu:11371   |/
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sean Chittenden | 1 Jun 2003 06:39
Gravatar

Re: compile error on cvs tip

> > > > auth.c: In function `pg_krb5_recvauth':
> > > > auth.c:294: structure has no member named `user'
> > > 
> > > Ooops, my fault --- I didn't build with Kerberos support after
> > > changing those field names.
> > > 
> > > Now that I think about it, there might be similar omissions in the
> > > PAM or Kerberos4 support --- can anyone try those?
> > 
> > krb4 code should be removed from PostgreSQL ASAP for various
> > insecurities in the protocol.  It's been removed from FreeBSD, MIT,
> > and Heimdal's code base and is officially unsupported as of June this
> > year.  -sc
> 
> Did we decide we _didn't_ want to remove krb4?  Removal seems like a
> good idea to me, but I am just checking if the consensus was to keep
> it.  I think someone said it was OK in a closed environment or
> something.  Maybe we need to document that it is not recommended.

Keep krb4 in the tree for 7.4, but before 7.4 gets released, the
documentation and release notes need to state that krb4 has been
depreciated and that it will be removed before 7.5.  I'll add submit a
patch for the updated verbiage in a bit.  -sc

--

-- 
Sean Chittenden

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruce Momjian | 1 Jun 2003 06:45
Picon

Re: "Adding missing from clause"


And patch now in queue.  :-)

---------------------------------------------------------------------------

Bruce Momjian wrote:
> 
> Added to TODO:
> 
> 	* Add config variable to prevent auto-adding missing FROM-clause
> 	  tables
> 
> 
> ---------------------------------------------------------------------------
> 
> Philip Warner wrote:
> > At 02:36 PM 29/04/2003 -0700, Josh Berkus wrote:
> > >I'd far rather have a fatal query error than have Postgres
> > >automatically insert the tables it thinks I wanted
> > 
> > I too would dearly like to see this.
> > 
> > 
> > ----------------------------------------------------------------
> > Philip Warner                    |     __---_____
> > Albatross Consulting Pty. Ltd.   |----/       -  \
> > (A.B.N. 75 008 659 498)          |          /( <at> )   ______---_
> > Tel: (+61) 0500 83 82 81         |                 _________  \
> > Fax: (+61) 03 5330 3172          |                 ___________ |
> > Http://www.rhyme.com.au          |                /           \|
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manfred Spraul | 1 Jun 2003 11:10

Re: ECPG thread-safety

Shridhar Daithankar wrote:

>2) Native freeBSD threads
>pthread.h in /usr/include and lc_r
>
>  
>
Do you know if FreeBSD supports pthread_rwlock with 
PTHREAD_PROCESS_SHARED? I'm trying to replace the LWLocks with 
pthread_rwlocks.

What about other Unices?
--
    Manfred

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Permalink | Reply | 0 comments |
headers
Peter Eisentraut | 1 Jun 2003 16:30
Picon
Gravatar

Re: default locale considered harmful? (was Re: [GENERAL]

Tom Lane writes:

> I think that a more general solution would be the ability to select a
> locale (and hence a sort order) per-column, as the SQL spec envisions.

It is a general solution, but not for this problem.  The problem was to
make all locales equally suitable for certain optimizations, not to make
locales available in more places.  I won't pretend to anyone that this
little change will bring us anywhere closer to a solution for that other
problem.

> Then you'd just select C locale for columns you wanted to do pattern
> matching for.

That's wrong, for a number of reasons:

First of all, I don't agree at all that cases where you want both pattern
matching and collation are rare; in fact, I rarely see a case where you
don't want both.  Designing a system on that assumption is not sound,
because all operations should be equally possible in all situations.

Second, we will eventually want pattern matching operations to be locale
aware.  Case-sensitive matching needs this, because case mappings depend
on the locale.  The character class features of POSIX regexps also need
this.  So you cannot make locales and well-performing pattern matching
mutually exclusive.

Third, keep in mind that datums with different locales cannot be combined
liberally.  So systems built the way you propose become crippled in ways
that will be hard to understand and justify.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Eisentraut | 1 Jun 2003 16:30
Picon
Gravatar

Re: Question about simple function folding optimization

Tom Lane writes:

> (the documentation build at developer.postgresql.org doesn't seem to
> have updated since before the server move :-()

The program called "onsgmls" (or maybe "nsgmls") is missing.  Marc, can
you please install it?  It should be in a package called "opensp".

--

-- 
Peter Eisentraut   peter_e <at> gmx.net

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo <at> postgresql.org)
Permalink | Reply | 1 comment |
headers
Rasmus Resen Amossen | 1 Jun 2003 17:50
Picon
Favicon

Re: Postgres config file: autocommit = off

>We have been there, done that, and decided it was a bad idea.  I suggest
>you do a little reading in the mail list archives.

I have searched the lists archives for the words "commit", "autocommit" and 
"transaction" but couldn't find any discussion on wheter to give a database 
administrator the option to turn automatic commit off  was is a good idea or 
not (not requirering the user to enter BEGIN; to start a transaction).

Do you know the title of the thread or some more details on where to find 
the arguments? I look forward to read that discussion. :-)

Personally I am managing a database for approx. 500 people which are all 
VERY dependant on the correctnes of the database. Sometimes, when we do 
manually fixes in the database, it takes a series of statements before our 
data mangeling leaves the databases in a consistent state again. Therefor it 
is a quite serious problem for us if we forget the BEGIN-word (which happens 
quite often :-( ), so we could really use the config file option mentioned.

Regards, Rasmus

_________________________________________________________________
Tag MSN Hotmail med dig på mobilen http://www.msn.dk/mobile

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo <at> postgresql.org so that your
message can get through to the mailing list cleanly
Permalink | Reply | 9 comments |

Gmane