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

2003-06-01 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 I don't understand why you call this a hack.  Pattern matching and string
 comparison simply work differently, so the proper solution is to use
 different operator classes.  After all, that's what operator classes exist
 for.  What is left to be desired?

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.
Then you'd just select C locale for columns you wanted to do pattern
matching for.

Admittedly, you'd still need the opclass-based approach for cases where
you wanted both pattern matching and a non-C-locale sort order ... but
I doubt that constitutes the majority of cases.

I guess my main concern is that we should not feel that this approach
takes the heat off us to support multiple locales.  As a solution to the
narrow problem of LIKE performance, it's okay --- but it's not getting
us any nearer to a solution to the general locale problem.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


[HACKERS] Use of Intel compiler on Linux

2003-06-01 Thread Peter Eisentraut
A German computer magazine (c't 7/2003) tested the Intel C/C++ compiler
suite on Linux.  Among the open-source projects they tried, PostgreSQL and
KDE were the only ones they couldn't get to compile at all.

I tried it out and made two simple changes (see below) to be able to
compile it.  If no one objects, I'll apply them.


diff -cr ../cvs-pgsql/src/include/storage/s_lock.h ./src/include/storage/s_lock.h
*** ../cvs-pgsql/src/include/storage/s_lock.h   Tue Apr 22 12:06:25 2003
--- ./src/include/storage/s_lock.h  Wed May 28 20:33:31 2003
***
*** 76,82 
  #if defined(HAS_TEST_AND_SET)


! #if defined(__GNUC__)
  /*
   * All the gcc inlines
   */
--- 76,82 
  #if defined(HAS_TEST_AND_SET)


! #if defined(__GNUC__) || defined(__ICC)
  /*
   * All the gcc inlines
   */
diff -cr ../cvs-pgsql/src/makefiles/Makefile.linux ./src/makefiles/Makefile.linux
*** ../cvs-pgsql/src/makefiles/Makefile.linux   Fri May 23 17:14:30 2003
--- ./src/makefiles/Makefile.linux  Wed May 28 20:44:32 2003
***
*** 1,5 
  AROPT = crs
! export_dynamic = -export-dynamic
  rpath = -Wl,-rpath,$(libdir)
  shlib_symbolic = -Wl,-Bsymbolic
  allow_nonpic_in_shlib = yes
--- 1,5 
  AROPT = crs
! export_dynamic = -Wl,-E
  rpath = -Wl,-rpath,$(libdir)
  shlib_symbolic = -Wl,-Bsymbolic
  allow_nonpic_in_shlib = yes

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] Postgres config file: autocommit = off

2003-06-01 Thread Tom Lane
Rasmus Resen Amossen [EMAIL PROTECTED] writes:
 Therefor: Are there any plans to give the administrator an OPTION to turn 
 the behavior off through a parameter autocommit = boolean in the config 
 file?

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.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] A few notes

2003-06-01 Thread Tom Lane
Mike Mascari [EMAIL PROTECTED] writes:
 ... is it possible the GEQO threshold, as a default, is too low?

It's been on the TODO list for awhile to investigate whether the current
default is still appropriate.  A lot of planner details have changed
since we last twiddled it, and you're not the first to suggest that it
may need to be twiddled again.  But no one's provided more than
anecdotal evidence.  If you want to do some measurements to determine
where the best crossover point is now, go to it ...

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


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

2003-06-01 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Has the single-byte LIKE penalty been eliminated, so we don't need to
  consider using C as the default locale for initdb, right?
 
 I'm still of the opinion that we should make C the default locale.
 But I'm not sure where the consensus is, so I've not made the change.
 
  If fixed, how was it done?
 
 Peter has provided a hack whereby one can create a LIKE-supporting index
 in a non-C locale.  But a *default* index in a non-C locale is still not
 going to support LIKE ... and the hacked index will not support ordinary
 comparison or ordering operators.  So I think there's still a lot left
 to be desired here.

So, my understanding is that you would create something such as:

CREATE INDEX iix ON tab (LIKE col)

and that does LIKE lookups and knows how to do col LIKE 'abc%', but it
can't be used for = or ORDER BY, but it can be used for equality tests?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


[HACKERS] regression in cvs tip

2003-06-01 Thread Joe Conway
I ran across a regression in unmodified cvs tip. On a 7.3.2 installation 
I can do:

create table tse(f1 int, f2 int[], f3 text[]);
insert into tse values(1,'{69,42,54}', '{g,d,e}');
# select * from tse where 1 in (select f1);
 f1 | f2 |   f3
++-
  1 | {69,42,54} | {g,d,e}
(1 row)
On cvs tip (from this morning, no local changes) I get:

create table tse(f1 int, f2 int[], f3 text[]);
insert into tse values(1,array[69,42,54], array['g','d','e']);
# select * from tse where 1 in (select f1);
The connection to the server was lost. Attempting reset: Failed.
connection pointer is NULL
!#
Here's the backtrace:

Program received signal SIGABRT, Aborted.
0xe002 in ?? ()
(gdb) bt
#0  0xe002 in ?? ()
#1  0x42028b93 in abort () from /lib/tls/libc.so.6
#2  0x081aeac0 in ExceptionalCondition (conditionName=0x42131a14  
[EMAIL PROTECTED]@`Â,
errorType=0x6 Address 0x6 out of bounds, fileName=0x0, 
lineNumber=245) at assert.c:46
#3  0x080cb99a in markTargetListOrigin (pstate=0x831322c, res=0x8313a08, 
var=0x83139dc) at parse_target.c:245
#4  0x080cb920 in markTargetListOrigins (pstate=0x831322c, 
targetlist=0x8313934) at parse_target.c:225
#5  0x080b689f in transformSelectStmt (pstate=0x831322c, stmt=0x8312e6c) 
at analyze.c:1779
#6  0x080b485f in transformStmt (pstate=0x831322c, parseTree=0x8312e6c, 
extras_before=0xbfffd6a4, extras_after=0xbfffd6a8)
at analyze.c:407
#7  0x080b46d3 in do_parse_analyze (parseTree=0x8312e6c, 
pstate=0x831322c) at analyze.c:234
#8  0x080b4695 in parse_sub_analyze (parseTree=0x8312e6c, 
parentParseState=0x8312be0) at analyze.c:213
#9  0x080c351c in transformExpr (pstate=0x8312be0, expr=0x8312ef8) at 
parse_expr.c:420
#10 0x080c2df7 in transformWhereClause (pstate=0x8312be0, 
clause=0x42131a14) at parse_clause.c:956
#11 0x080b68aa in transformSelectStmt (pstate=0x8312be0, stmt=0x8312f78) 
at analyze.c:1782
#12 0x080b485f in transformStmt (pstate=0x8312be0, parseTree=0x8312f78, 
extras_before=0xbfffd7f4, extras_after=0xbfffd7f8)
at analyze.c:407
#13 0x080b46d3 in do_parse_analyze (parseTree=0x8312f78, 
pstate=0x8312be0) at analyze.c:234
#14 0x080b45ec in parse_analyze (parseTree=0x8312f78, paramTypes=0x0, 
numParams=0) at analyze.c:159
#15 0x0815a07c in pg_analyze_and_rewrite (parsetree=0x8312f78, 
paramTypes=0x0, numParams=0) at postgres.c:482
#16 0x0815a39f in exec_simple_query (query_string=0x83129c8 select * 
from tse where 1 in (select f1);) at postgres.c:793
#17 0x0815c0b8 in PostgresMain (argc=4, argv=0x8299cb8, 
username=0x8299c80 postgres) at postgres.c:2730
#18 0x0813a910 in BackendFork (port=0x82a6fe8) at postmaster.c:2473
#19 0x0813a44e in BackendStartup (port=0x82a6fe8) at postmaster.c:2095
#20 0x08138f00 in ServerLoop () at postmaster.c:1049
#21 0x0813875a in PostmasterMain (argc=5, argv=0x8299428) at 
postmaster.c:829
#22 0x08110183 in main (argc=5, argv=0xbfffe1b4) at main.c:211
#23 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

Any ideas?

Thanks,

Joe

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


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

2003-06-01 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 So, my understanding is that you would create something such as:
   CREATE INDEX iix ON tab (LIKE col)
 and that does LIKE lookups and knows how to do col LIKE 'abc%', but it
 can't be used for = or ORDER BY, but it can be used for equality tests?

Hm.  Right at the moment, it wouldn't be used for equality tests unless
you spelled equality as a ~=~ b.  I wonder whether that's necessary
though; couldn't we dispense with that operator and use ordinary
equality as the BTEqual member of these opclasses?  Are there any
locales that claim that not-physically-identical strings are equal?

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Re: [HACKERS] regression in cvs tip

2003-06-01 Thread Tom Lane
Joe Conway [EMAIL PROTECTED] writes:
 I ran across a regression in unmodified cvs tip.

Looks like I forgot to make markTargetListOrigin handle outer-scope
Vars (those with varlevelsup  0) :-(.  Will fix, thanks for report!

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


[HACKERS] The Register moving to Bricolage + PostgreSQL...

2003-06-01 Thread Dave Page
...which is nice:

http://www.theregister.co.uk/content/31/30959.html

Regards, Dave



---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


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

2003-06-01 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  So, my understanding is that you would create something such as:
  CREATE INDEX iix ON tab (LIKE col)
  and that does LIKE lookups and knows how to do col LIKE 'abc%', but it
  can't be used for = or ORDER BY, but it can be used for equality tests?
 
 Hm.  Right at the moment, it wouldn't be used for equality tests unless
 you spelled equality as a ~=~ b.  I wonder whether that's necessary
 though; couldn't we dispense with that operator and use ordinary
 equality as the BTEqual member of these opclasses?  Are there any
 locales that claim that not-physically-identical strings are equal?

Let me see if I understand.  

Our default indexes will be able to do =, , , ORDER BY, and the
special index will be able to do LIKE, ORDER BY, and maybe equals.  Do I
have that correct?

Looking at CVS, I see the warning about non-C locales has been removed. 
Should we instead mention the new LIKE index method?

# (Be sure to maintain the correspondence with locale_is_like_safe() in 
selfuncs.c.)
if test x`pg_getlocale COLLATE` != xC  test x`pg_getlocale COLLATE` != 
xPOSIX; then
echo This locale setting will prevent the use of indexes for pattern 
matching
echo operations.  If that is a concern, rerun $CMDNAME with the collation 
order
echo set to \C\.  For more information see the Administrator's Guide.
fi

Doing LIKE with single-byte encodings would be easy because it would be
only 256 compares to find the min/max char values, but that doesn't work
with multi-byte encodings, right?

This LIKE/encoding problem is a tricky one because it gives poor
performance with little warning to users.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (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 [EMAIL PROTECTED])


Re: [HACKERS] compile error on cvs tip

2003-06-01 Thread Bruce Momjian
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
  [EMAIL PROTECTED]   |  (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 [EMAIL PROTECTED])


Re: [HACKERS] Please, apply patch for current CVS

2003-06-01 Thread Bruce Momjian

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: [EMAIL PROTECTED]
 
 
 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?
 
 http://archives.postgresql.org
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


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

2003-06-01 Thread Bruce Momjian
Tom Lane wrote:
 Peter Eisentraut [EMAIL PROTECTED] 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
  [EMAIL PROTECTED]   |  (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] Adding missing from clause

2003-06-01 Thread Bruce Momjian

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)  |  /(@)   __---_
 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
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (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 [EMAIL PROTECTED])


Re: [HACKERS] compile error on cvs tip

2003-06-01 Thread Sean Chittenden
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 [EMAIL PROTECTED]


Re: [HACKERS] Adding missing from clause

2003-06-01 Thread Bruce Momjian

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)  |  /(@)   __---_
  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
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly
  
 
 -- 
   Bruce Momjian|  http://candle.pha.pa.us
   [EMAIL PROTECTED]   |  (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 [EMAIL PROTECTED])
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] ECPG thread-safety

2003-06-01 Thread Manfred Spraul
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