Re: [PATCHES] Add function to return the thread safety status of libpq

[Qingqing Zhou]

"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> Is there a point in checking the thread-safety of
> libpq when you can't check the thread-safety of libc?
>

Exactly :-(

Regards,
Qingqing



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] Add function to return the thread safety status of libpq

[Tom Lane]

Qingqing Zhou <[EMAIL PROTECTED]> writes:
> This is half of an item in TODO list. I patch this because now pgbench is
> threaded in Win32, so it is better to check thread safety of libpq.dll.

ISTM this was proposed once before, and rejected on the grounds that
no one could present a convincing use case.  Exactly where is there
an application that will support both threaded and nonthreaded libpq
*at run time*?  Is there a point in checking the thread-safety of
libpq when you can't check the thread-safety of libc?

BTW, an acceptable patch that changes libpq's API would require
documentation and exports.txt updates...

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[PATCHES] Add function to return the thread safety status of libpq

[Qingqing Zhou]

This is half of an item in TODO list. I patch this because now pgbench is
threaded in Win32, so it is better to check thread safety of libpq.dll.

Patch ecpg could be done in a similar way, but I am not sure how we will
use this function there ...

Regards,
Qingqing

---

Index: fe-connect.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.324
diff -c -r1.324 fe-connect.c
*** fe-connect.c22 Nov 2005 18:17:32 -  1.324
--- fe-connect.c3 Dec 2005 05:15:29 -
***
*** 2860,2865 
--- 2860,2875 
return PG_PROTOCOL_MAJOR(conn->pversion);
  }

+ bool
+ PQthreadSafe(void)
+ {
+ #ifdef ENABLE_THREAD_SAFETY
+   return true;
+ #else
+   return false;
+ #endif
+ }
+
  int
  PQserverVersion(const PGconn *conn)
  {
Index: libpq-fe.h
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/libpq-fe.h,v
retrieving revision 1.122
diff -c -r1.122 libpq-fe.h
*** libpq-fe.h  23 Nov 2005 04:23:28 -  1.122
--- libpq-fe.h  3 Dec 2005 05:15:29 -
***
*** 264,269 
--- 264,270 
  extern const char *PQparameterStatus(const PGconn *conn,
  const char *paramName);
  extern intPQprotocolVersion(const PGconn *conn);
+ extern bool   PQthreadSafe(void);
  extern intPQserverVersion(const PGconn *conn);
  extern char *PQerrorMessage(const PGconn *conn);
  extern intPQsocket(const PGconn *conn);


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > Yep, I am digging through snprintf.c now to try find a solution.
> 
> The cleanest solution is probably to fix things so that dopr_outch is
> aware of whether it's working for sprintf or fprintf, and can dump the
> buffer directly to the file when it gets full in the fprintf case.
> Its existing API would need to be changed a bit ... maybe pass it a
> struct containing what it needs, instead of having all the layers of
> code know what to pass.

OK, snprintf.c fixed.  I added a 'stream' and outlen parameter to all
the calls, and cleaned up the switch() statement that was outputing
twice.  When we were outputing just to a string, it didn't matter, but
now that we are also outputting to a stream, it does.

Passed regression and initdb tests, and factorial(4000) works!

(I could have done the struct but that seemed too invasive.)

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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
Index: src/port/snprintf.c
===
RCS file: /cvsroot/pgsql/src/port/snprintf.c,v
retrieving revision 1.29
diff -c -c -r1.29 snprintf.c
*** src/port/snprintf.c 15 Oct 2005 02:49:51 -  1.29
--- src/port/snprintf.c 3 Dec 2005 04:23:00 -
***
*** 64,70 
  
  /*static char _id[] = "$PostgreSQL: pgsql/src/port/snprintf.c,v 1.29 
2005/10/15 02:49:51 momjian Exp $";*/
  
! static void dopr(char *buffer, const char *format, va_list args, char *end);
  
  /* Prevent recursion */
  #undefvsnprintf
--- 64,70 
  
  /*static char _id[] = "$PostgreSQL: pgsql/src/port/snprintf.c,v 1.29 
2005/10/15 02:49:51 momjian Exp $";*/
  
! static int dopr(FILE *stream, char *buffer, const char *format, va_list args, 
char *end);
  
  /* Prevent recursion */
  #undefvsnprintf
***
*** 73,89 
  #undeffprintf
  #undefprintf
  
! int
! pg_vsnprintf(char *str, size_t count, const char *fmt, va_list args)
  {
char   *end;
  
!   str[0] = '\0';
!   end = str + count - 1;
!   dopr(str, fmt, args, end);
!   if (count > 0)
end[0] = '\0';
!   return strlen(str);
  }
  
  int
--- 73,100 
  #undeffprintf
  #undefprintf
  
!   
! static int
! pg_fvsnprintf(FILE *stream, char *str, size_t count, const char *fmt, va_list 
args)
  {
char   *end;
+   int len;
  
!   if (str)
!   {
!   str[0] = '\0';
!   end = str + count - 1;
!   }
!   len = dopr(stream, str, fmt, args, end);
!   if (str && count > 0)
end[0] = '\0';
!   return len;
! }
! 
! int
! pg_vsnprintf(char *str, size_t count, const char *fmt, va_list args)
! {
!   return pg_fvsnprintf(NULL, str, count, fmt, args);
  }
  
  int
***
*** 93,99 
va_list args;
  
va_start(args, fmt);
!   len = pg_vsnprintf(str, count, fmt, args);
va_end(args);
return len;
  }
--- 104,110 
va_list args;
  
va_start(args, fmt);
!   len = pg_fvsnprintf(NULL, str, count, fmt, args);
va_end(args);
return len;
  }
***
*** 103,115 
  {
int len;
va_list args;
!   charbuffer[4096];
  
va_start(args, fmt);
!   len = pg_vsnprintf(buffer, (size_t) 4096, fmt, args);
va_end(args);
/* limit output to string */
!   StrNCpy(str, buffer, (len + 1 < 4096) ? len + 1 : 4096);
return len;
  }
  
--- 114,126 
  {
int len;
va_list args;
!   charbuffer[8192];   /* arbitrary limit */
  
va_start(args, fmt);
!   len = pg_fvsnprintf(NULL, buffer, (size_t) 4096, fmt, args);
va_end(args);
/* limit output to string */
!   StrNCpy(str, buffer, (len + 1 < 8192) ? len + 1 : 8192);
return len;
  }
  
***
*** 118,131 
  {
int len;
va_list args;
-   charbuffer[4096];
-   char   *p;
  
va_start(args, fmt);
!   len = pg_vsnprintf(buffer, (size_t) 4096, fmt, args);
va_end(args);
-   for (p = buffer; *p; p++)
-   putc(*p, stream);
return len;
  }
  
--- 129,138 
  {
int len;
va_list args;
  
va_start(args, fmt);
!   len = pg_fvsnprintf(stream, NULL, 0, fmt, args);
va_end(args);
return len;
  }
  
***
*** 134,166 
  {
int len;
va_list args;
-   charbuffer[4096];
-   char   *p;
  
va_start(args, fmt);
!   l

Re: [PATCHES] Allow an alias for the target table in UPDATE/DELETE

[Atsushi Ogawa]

Thanks for comments. I modified the patch.Tom Lane wrote:> Atsushi Ogawa <[EMAIL PROTECTED]> writes:> > (2)About processing when column identifier of SET clause is specified
> > like 'AAA.BBB'. 'AAA' is a composite column now. When an alias for> > target table is supported, 'AAA' is a composite column or a table.> > How do we distinguish these?> > You don't, which is why you can't put an alias on a SET target.
I stop applying an alias to a SET target.> Increasing the reserved-ness of SET isn't real attractive either.OK. I changed the syntax rule of an alias of UPDATE/DELETE target fromColId to IDENT. This doesn't change reserved words though candidates
of that alias decreases.--- Atsushi Ogawa


allow_alias_update.patch
Description: Binary data

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

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Yep, I am digging through snprintf.c now to try find a solution.

The cleanest solution is probably to fix things so that dopr_outch is
aware of whether it's working for sprintf or fprintf, and can dump the
buffer directly to the file when it gets full in the fprintf case.
Its existing API would need to be changed a bit ... maybe pass it a
struct containing what it needs, instead of having all the layers of
code know what to pass.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So this is a psql bug?

Not here.  Do you see it?

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Tom Lane wrote:
>> Doh.  OK, we gotta fix it then.  But what are you going to do when you
>> can't malloc enough memory?  You can't ereport in a client environment,
>> and there's no API for printf to report failure.

> Yep, I am digging through snprintf.c now to try find a solution.

Well, there's always the option of going back to plan B, which is not
using printf for strings that might be long.  AFAICS it would only be
a convenience for psql, since it's not doing any real conversions,
just inserting the right number of spaces.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > Tom Lane wrote:
> >> That would only affect a standalone backend, however, not normal
> >> operation.
> 
> > Ah, psql itself is using the same buggy snprintf.c.
> 
> Doh.  OK, we gotta fix it then.  But what are you going to do when you
> can't malloc enough memory?  You can't ereport in a client environment,
> and there's no API for printf to report failure.

Yep, I am digging through snprintf.c now to try find a solution.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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: Don't 'kill -9' the postmaster

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Tom Lane wrote:
>> That would only affect a standalone backend, however, not normal
>> operation.

> Ah, psql itself is using the same buggy snprintf.c.

Doh.  OK, we gotta fix it then.  But what are you going to do when you
can't malloc enough memory?  You can't ereport in a client environment,
and there's no API for printf to report failure.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Bruce Momjian wrote:
> > If you run the query that fails in a standalone backend, do you get
> > something like "(typeid = 1700, len = -1, typmod = -1, byval = f)"
> > at the end of the line, or is that part truncated too?
> 
> I found the cause.  I traced into printf then realized I was not in libc
> but port/snprintf.c, and I see 4096 defined for those buffers.  I will
> work on a patch to make it dynamic.  At the time I think there was
> thought that 4096 was as large as it ever needed to be, but obviously
> this was wrong. I think Win32 would see the same failure because it used
> port/snprintf.c too.

My Win32 8.1 platform is fine so Win32 must not use port/snprintf.c.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > Tom Lane wrote:
> >> Uh, how is control getting to snprintf?  I don't see that used either
> >> in numeric.c or in printtup.c.
> 
> > I am seeing it in the standalone backend here:
> 
> > debugtup (slot=0x856e0b0, self=0x84306d0) at printtup.c:548
> > 548 printatt((unsigned) i + 1, typeinfo->attrs[i], 
> > value);
> 
> That would only affect a standalone backend, however, not normal
> operation.

Ah, psql itself is using the same buggy snprintf.c.  That would explain
the long dash line, but short digits.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Tom Lane wrote:
>> Uh, how is control getting to snprintf?  I don't see that used either
>> in numeric.c or in printtup.c.

> I am seeing it in the standalone backend here:

>   debugtup (slot=0x856e0b0, self=0x84306d0) at printtup.c:548
>   548 printatt((unsigned) i + 1, typeinfo->attrs[i], 
> value);

That would only affect a standalone backend, however, not normal
operation.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > I found the cause.  I traced into printf then realized I was not in libc
> > but port/snprintf.c, and I see 4096 defined for those buffers.
> 
> Uh, how is control getting to snprintf?  I don't see that used either
> in numeric.c or in printtup.c.

I am seeing it in the standalone backend here:

debugtup (slot=0x856e0b0, self=0x84306d0) at printtup.c:548
548 printatt((unsigned) i + 1, typeinfo->attrs[i], 
value);
(gdb) s
printatt (attributeId=1, attributeP=0x856efa4, value=0x857201c "1", '0' 
...) at printtup.c:480
480 printf("\t%2d: %s%s%s%s\t(typeid = %u, len = %d, typmod 
= %d, byval = %c)\n",

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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: Don't 'kill -9' the postmaster

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> I found the cause.  I traced into printf then realized I was not in libc
> but port/snprintf.c, and I see 4096 defined for those buffers.

Uh, how is control getting to snprintf?  I don't see that used either
in numeric.c or in printtup.c.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

[PATCHES] Patch for gripe about pg_dump -C not dumping database privileges

[Tom Lane]

Attached is a proposed patch for bug #2085.  It's pretty grotty because
it introduces a new TOC tag type into the pg_dump format, which makes it
incompatible with existing pg_restores; so I think we probably couldn't
back-patch this, it'd have to be treated as a new feature for 8.2.
I don't see any other way to do it, though, because we want pg_restore
to emit the information under different conditions than those under
which it emits regular object ACLs (namely, only if -C mode).

Comments, better ideas?  Should we just leave well enough alone?
IMHO #2085 is a definition disagreement, not an outright bug.

regards, tom lane


*** src/bin/pg_dump/pg_backup_archiver.c.orig   Tue Nov 22 16:06:41 2005
--- src/bin/pg_dump/pg_backup_archiver.cFri Dec  2 17:01:46 2005
***
*** 1877,1882 
--- 1877,1885 
  
if (!ropt->create && strcmp(te->desc, "DATABASE") == 0)
return 0;
+   if ((!ropt->create || ropt->aclsSkip) &&
+   strcmp(te->desc, "DATABASE ACL") == 0)
+   return 0;
  
/* Check if tablename only is wanted */
if (ropt->selTypes)
*** src/bin/pg_dump/pg_dump.c.orig  Tue Nov 22 16:06:41 2005
--- src/bin/pg_dump/pg_dump.c   Fri Dec  2 16:54:48 2005
***
*** 1168,1179 
--- 1168,1181 
i_oid,
i_dba,
i_encoding,
+   i_datacl,
i_tablespace;
CatalogId   dbCatId;
DumpId  dbDumpId;
const char *datname,
   *dba,
   *encoding,
+  *datacl,
   *tablespace;
  
datname = PQdb(g_conn);
***
*** 1190,1206 
--- 1192,1222 
appendPQExpBuffer(dbQry, "SELECT tableoid, oid, "
  "(%s datdba) as dba, "
  
"pg_encoding_to_char(encoding) as encoding, "
+ "datacl, "
  "(SELECT spcname FROM 
pg_tablespace t WHERE t.oid = dattablespace) as tablespace "
  "FROM pg_database "
  "WHERE datname = ",
  username_subquery);
appendStringLiteral(dbQry, datname, true);
}
+   else if (g_fout->remoteVersion >= 70300)
+   {
+   appendPQExpBuffer(dbQry, "SELECT tableoid, oid, "
+ "(%s datdba) as dba, "
+ 
"pg_encoding_to_char(encoding) as encoding, "
+ "datacl, "
+ "NULL as tablespace "
+ "FROM pg_database "
+ "WHERE datname = ",
+ username_subquery);
+   appendStringLiteral(dbQry, datname, true);
+   }
else if (g_fout->remoteVersion >= 70100)
{
appendPQExpBuffer(dbQry, "SELECT tableoid, oid, "
  "(%s datdba) as dba, "
  
"pg_encoding_to_char(encoding) as encoding, "
+ "NULL as datacl, "
  "NULL as tablespace "
  "FROM pg_database "
  "WHERE datname = ",
***
*** 1214,1219 
--- 1230,1236 
  "oid, "
  "(%s datdba) as dba, "
  
"pg_encoding_to_char(encoding) as encoding, "
+ "NULL as datacl, "
  "NULL as tablespace "
  "FROM pg_database "
  "WHERE datname = ",
***
*** 1244,1255 
--- 1261,1274 
i_oid = PQfnumber(res, "oid");
i_dba = PQfnumber(res, "dba");
i_encoding = PQfnumber(res, "encoding");
+   i_datacl = PQfnumber(res, "datacl");
i_tablespace = PQfnumber(res, "tablespace");
  
dbCatId.tableoid = atooid(PQgetvalue(res, 0, i_tableoid));
dbCatId.oid = atooid(PQgetvalue(res, 0, i_oid));
dba = PQgetvalue(res, 0, i_dba);
encoding = PQgetvalue(res, 0, i_encoding);
+   datacl = PQgetvalue(res, 0, i_datacl);
tablespace =

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Michael Fuhr wrote:
> On Fri, Dec 02, 2005 at 04:30:54PM -0500, Tom Lane wrote:
> > Bruce Momjian  writes:
> > > Wow, check this out:
> > >   test=> SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
> > > It works fine!  I have all the digits, and the trailing 1.0:
> > >   01.
> > > while SELECT pow(10::numeric, 1) fails.
> > 
> > That's just about as wacky as can be, because numeric_text() is
> > implemented on top of numeric_out() ... there's no way that numeric_out
> > can be delivering the wrong answer if the cast produces the right text.
> > So somewhere between numeric_out and the delivery to the client,
> > something's getting confused.  I think it's time you got out your
> > debugger and started tracing through the backend ...
> 
> Bruce, have you run a process trace on the backend to see if write()
> (or whatever) is writing the correct number of characters?  What
> exactly is your output device and how are you connected to the
> machine that runs the backend (ssh to a remote box from an xterm,
> sitting in front of the box's VT52 serial console, etc.)?
> 
> If you run the query that fails in a standalone backend, do you get
> something like "(typeid = 1700, len = -1, typmod = -1, byval = f)"
> at the end of the line, or is that part truncated too?

I found the cause.  I traced into printf then realized I was not in libc
but port/snprintf.c, and I see 4096 defined for those buffers.  I will
work on a patch to make it dynamic.  At the time I think there was
thought that 4096 was as large as it ever needed to be, but obviously
this was wrong. I think Win32 would see the same failure because it used
port/snprintf.c too.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 1: 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: [PATCHES] Numeric 508 datatype

[Michael Fuhr]

On Fri, Dec 02, 2005 at 04:30:54PM -0500, Tom Lane wrote:
> Bruce Momjian  writes:
> > Wow, check this out:
> > test=> SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
> > It works fine!  I have all the digits, and the trailing 1.0:
> > 01.
> > while SELECT pow(10::numeric, 1) fails.
> 
> That's just about as wacky as can be, because numeric_text() is
> implemented on top of numeric_out() ... there's no way that numeric_out
> can be delivering the wrong answer if the cast produces the right text.
> So somewhere between numeric_out and the delivery to the client,
> something's getting confused.  I think it's time you got out your
> debugger and started tracing through the backend ...

Bruce, have you run a process trace on the backend to see if write()
(or whatever) is writing the correct number of characters?  What
exactly is your output device and how are you connected to the
machine that runs the backend (ssh to a remote box from an xterm,
sitting in front of the box's VT52 serial console, etc.)?

If you run the query that fails in a standalone backend, do you get
something like "(typeid = 1700, len = -1, typmod = -1, byval = f)"
at the end of the line, or is that part truncated too?

-- 
Michael Fuhr

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

   http://archives.postgresql.org

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Wow, check this out:
>   test=> SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)
> It works fine!  I have all the digits, and the trailing 1.0:
>   01.
> while SELECT pow(10::numeric, 1) fails.

That's just about as wacky as can be, because numeric_text() is
implemented on top of numeric_out() ... there's no way that numeric_out
can be delivering the wrong answer if the cast produces the right text.
So somewhere between numeric_out and the delivery to the client,
something's getting confused.  I think it's time you got out your
debugger and started tracing through the backend ...

regards, tom lane

---(end of broadcast)---
TIP 1: 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: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > Tom Lane wrote:
> >> If that gives the right answer then the NUMERIC code is off the hook,
> >> and what you've got is a strange limitation on output column length.
> 
> > test=> select length((pow(10::numeric, 131071))::text);
> >  length
> > 
> >  131089
> > (1 row)
> 
> > Looks good.  From psql I just tried:
> 
> > SELECT repeat('x', 4000);
> 
> > and got 4k x's, and SELECT repeat('x', 8000) returns 8k x's, so that works.
> 
> Curiouser and curiouser.  How about if you repeat 4k or 8k '1's?  If the

1's print just fine too.

> behavior is different for letters and digits then I'd look at the column
> justification logic in psql's printing code.

Again, I checked on a stand-alone backend and saw the same failures, so
it isn't psql.

Wow, check this out:

test=> SELECT CAST (pow(10::numeric, 1) + 1 AS TEXT)

It works fine!  I have all the digits, and the trailing 1.0:

01.

while SELECT pow(10::numeric, 1) fails.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 6: explain analyze is your friend

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Tom Lane wrote:
>> If that gives the right answer then the NUMERIC code is off the hook,
>> and what you've got is a strange limitation on output column length.

>   test=> select length((pow(10::numeric, 131071))::text);
>length
>   
>131089
>   (1 row)

> Looks good.  From psql I just tried:

>   SELECT repeat('x', 4000);

> and got 4k x's, and SELECT repeat('x', 8000) returns 8k x's, so that works.

Curiouser and curiouser.  How about if you repeat 4k or 8k '1's?  If the
behavior is different for letters and digits then I'd look at the column
justification logic in psql's printing code.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Simon Riggs wrote:
> On Fri, 2005-12-02 at 14:09 -0500, Bruce Momjian wrote:
> 
> > I ran your SELECT pow(10::numeric, 131071), and gain, 4096 0's are
> > displayed on my screen.  SELECT pow(10::numeric, 7000) and SELECT
> > pow(10::numeric, 1) generate identical displays on my screen.
> 
> Are you saying there is a bug with or without my patch?

Without.

> Can we get the usual release levels/cvstip, ports, etc.

Sorry, BSD/OS 4.3.1, CVS HEAD, no patches.

> Are you connecting across network/ protocol differences...

psql and the backend are on the same machine.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 5: don't forget to increase your free space map settings

Re: [PATCHES] Numeric 508 datatype

[Simon Riggs]

On Fri, 2005-12-02 at 14:09 -0500, Bruce Momjian wrote:

> I ran your SELECT pow(10::numeric, 131071), and gain, 4096 0's are
> displayed on my screen.  SELECT pow(10::numeric, 7000) and SELECT
> pow(10::numeric, 1) generate identical displays on my screen.

Are you saying there is a bug with or without my patch?

Can we get the usual release levels/cvstip, ports, etc.

Are you connecting across network/ protocol differences...

[Just out of interest, has anybody ever used a number bigger than 10^20
in an application? My understanding is that the number of atoms in the
universe is around 10^80. Accuracy is needed during calculation, but
much less so during storage.]

Thanks,

Best Regards, Simon Riggs



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > I just tested from a standalone backend:
> > backend> select pow(10::numeric, 131071) + 1
> > and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it
> > must be something in the backend.
> 
> If the backend is truncating the result length, I don't see why psql
> would decide it needs 12K dashes for the header.  There's something
> awfully fishy going on in your machine.
> 
> Try something like
> 
> regression=# select length((pow(10::numeric, 131071))::text);
>  length
> 
>  131089
> (1 row)
> 
> If that gives the right answer then the NUMERIC code is off the hook,
> and what you've got is a strange limitation on output column length.

test=> select length((pow(10::numeric, 131071))::text);
 length

 131089
(1 row)

Looks good.  From psql I just tried:

SELECT repeat('x', 4000);

and got 4k x's, and SELECT repeat('x', 8000) returns 8k x's, so that works.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> I just tested from a standalone backend:
>   backend> select pow(10::numeric, 131071) + 1
> and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it
> must be something in the backend.

If the backend is truncating the result length, I don't see why psql
would decide it needs 12K dashes for the header.  There's something
awfully fishy going on in your machine.

Try something like

regression=# select length((pow(10::numeric, 131071))::text);
 length

 131089
(1 row)

If that gives the right answer then the NUMERIC code is off the hook,
and what you've got is a strange limitation on output column length.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Actually, no.  If I cut'n paste the number from psql to
> > > cat > foo
> > >  
> > > then only 4096 chars are copied.  (Amusingly, I can't add a newline to
> > > ^D and close the file.  I must delete one char to do that.)
> > 
> > Hmm, cut buffer limitation in X or someplace?  I definitely get the
> > right number of characters into the file written with \g, and what looks
> > like a reasonable number of screensful of plain psql output.  If Bruce
> > is seeing the right number of dashes and the wrong number of data
> > characters in his \g output then *something* is pretty weird there.
> 
> Well, I just tried the \g test and it is correct (12675 digits or so).

I just tested from a standalone backend:

backend> select pow(10::numeric, 131071) + 1

and got 4095 zeros and no trailing '1' (wrong), so it isn't psql, it
must be something in the backend.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Joshua D. Drake]

On Fri, 2005-12-02 at 15:12 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > 
> > > OK, updated text:
> > > 
> > >   --with-openssl  build with OpenSSL support
> > >   --with-libedit-preferred  prefer Libedit over Libreadline
> > >   --without-readline  do not use Libreadline/Libedit line editing
> > >   --without-zlib  do not use Zlib
> > 
> > This all seems kind of extra... Why not just:
> > 
> > --with-libedit  Use libedit instead of readline
> > --with-readline Use readline instead of libedit (default)
> > --without-readline Use when readline is not available
> > 
> 
> Did you read my later posting?  There is no reasonable default for
> those unless we want to disable libedit detection by default,

Well that is why I said that --with-readline is the default ;)

>  and as Tom
> mentioned, for OSX it isn't even clear which one you have found.

Hmmm... Can we change the config options based on FreeBSD/OSX? Where
if it is that platform libedit is the default?

Of course is OSX can't determine which one it is giving to the user that
seems like a PITA.

Joshua D. Drake


> 
-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl, ODBCng - http://www.commandprompt.com/



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [PATCHES] Numeric 508 datatype

[Alvaro Herrera]

Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Actually, no.  If I cut'n paste the number from psql to
> > cat > foo
> >  
> > then only 4096 chars are copied.  (Amusingly, I can't add a newline to
> > ^D and close the file.  I must delete one char to do that.)
> 
> Hmm, cut buffer limitation in X or someplace?  I definitely get the
> right number of characters into the file written with \g, and what looks
> like a reasonable number of screensful of plain psql output.  If Bruce
> is seeing the right number of dashes and the wrong number of data
> characters in his \g output then *something* is pretty weird there.

Well, I just tried the \g test and it is correct (12675 digits or so).

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Bruce Momjian]

Joshua D. Drake wrote:
> 
> > OK, updated text:
> > 
> >   --with-openssl  build with OpenSSL support
> >   --with-libedit-preferred  prefer Libedit over Libreadline
> >   --without-readline  do not use Libreadline/Libedit line editing
> >   --without-zlib  do not use Zlib
> 
> This all seems kind of extra... Why not just:
> 
> --with-libeditUse libedit instead of readline
> --with-readline   Use readline instead of libedit (default)
> --without-readline Use when readline is not available
> 

Did you read my later posting?  There is no reasonable default for
those unless we want to disable libedit detection by default, and as Tom
mentioned, for OSX it isn't even clear which one you have found.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 1: 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: [PATCHES] Numeric 508 datatype

[Tom Lane]

Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually, no.  If I cut'n paste the number from psql to
> cat > foo
>  
> then only 4096 chars are copied.  (Amusingly, I can't add a newline to
> ^D and close the file.  I must delete one char to do that.)

Hmm, cut buffer limitation in X or someplace?  I definitely get the
right number of characters into the file written with \g, and what looks
like a reasonable number of screensful of plain psql output.  If Bruce
is seeing the right number of dashes and the wrong number of data
characters in his \g output then *something* is pretty weird there.

regards, tom lane

---(end of broadcast)---
TIP 1: 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: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Please try Tom's \g test:

test=> select factorial(4000)
test-> \g /tmp/x
test=> \q
$ wc -c /tmp/x
   20881 /tmp/x

Do you see a number greater than 20881, something like 3?

---

Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > So this is a psql bug?
> > 
> > Not here.  Do you see it?
> 
> Actually, no.  If I cut'n paste the number from psql to
> 
> cat > foo
>  
> 
> then only 4096 chars are copied.  (Amusingly, I can't add a newline to
> ^D and close the file.  I must delete one char to do that.)
> 
> However if I open vim and paste there, the whole 12000+delta chars are
> copied.
> 
> So it must be a bug in Bruce's procedure I guess ...
> 
> -- 
> Alvaro Herrerahttp://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> 
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
> 
>http://www.postgresql.org/docs/faq
> 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 5: don't forget to increase your free space map settings

Re: [PATCHES] Numeric 508 datatype

[Alvaro Herrera]

Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So this is a psql bug?
> 
> Not here.  Do you see it?

Actually, no.  If I cut'n paste the number from psql to

cat > foo
 

then only 4096 chars are copied.  (Amusingly, I can't add a newline to
^D and close the file.  I must delete one char to do that.)

However if I open vim and paste there, the whole 12000+delta chars are
copied.

So it must be a bug in Bruce's procedure I guess ...

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [PATCHES] Case Conversion Fix for MB Chars

[Volkan YAZICI]

Last minute edit:
src/test/mb seems a little bit old. I've tested SQL files in
src/test/mb/sql with the expected results in src/test/mb/expected
manually and it worked. (Output files need a little bit editing, like
removing lines similar to "CREATE TABLE".) But it'll be better if any
EUC users will try 'em manually too.

On 12/2/05, Bruce Momjian  wrote:
> Volkan YAZICI wrote:
> > After Tom's advice (he was doubtful about the patch), while I was
> > thinking about how to improve the spectrum of tests, decided to use
> > src/test/mb. In the tests, patch just succeded for unicode and failed
> > on big5, euc_cn, euc_jp, euc_kr, euc_tw, mule_internal, sjis
> > encodings. Fails' reason can be my wrong configuration too. (I've made
> > tests on a both unicode and latin-5 encoded databases.)
>
> Do those encodings even have uppercase letters?

According to what IRC folks, yes.

> People have talked about ICU but I don't know if anyone is working on it
> now.

Furthermore, there're some unofficial ICU patches for PostgreSQL
around. Like the one @
http://people.freebsd.org/~girgen/postgresql-icu/README.html

> I think the big problem is that while your patch works for some cases,
> it fails for others

As I mentioned in the above, it seems like it's working for other ones too.

> and there is no good way to know/test which will
> work and which will not. Is that accurate?

You don't want to commit this patch because it breaks[*] EUC like
encodings. But OTOH, it fixes LatinN and UNICODE encodings. I'm really
wondering, while we're trying to protect the EUC encodings still
working, why there's not any EUC users around to take care of EUC
tests? Doesn't EUC have any problems? Do ILIKE, upper/lower work for
them properly?

[*] If I didn't make a mistake, manual tests succeded for EUC like
encodings too.

You can think the reverse of the subject too. Think LatinN and UNICODE
as working and somebody submitted a patch which fixes EUC encodings by
breaking the previous ones. What will be the reaction of PostgreSQL
team in this situation?


Regards.

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

   http://archives.postgresql.org

Re: [PATCHES] Numeric 508 datatype

[Alvaro Herrera]

Bruce Momjian wrote:

> I tried your \g test and the file size difference is the length of the
> dashed line in the file, not the number of digits display, which are
> both 4096.  One has 12550 dashes, the other 19950 dashes.

So this is a psql bug?  I can count the correct number of chars with
SPI:


alvherre=# create or replace function factorial_length(int) returns int 
language plphp
alvherre-# as $$ $r = spi_exec("select factorial($args[0])");
alvherre$# $row = spi_fetch_row($r);
alvherre$# return strlen($row['factorial']); $$; 

alvherre=# select factorial_length(4000);
 factorial_length 
--
12674
(1 fila)

alvherre=# select factorial_length(6000);
 factorial_length 
--
20066
(1 fila)

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 1: 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: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Both are 4096 characters.

You forgot the part that scrolled off the screen.  Or else your
installation is broken.

I get this for factorial(4000)
 
182880195151406501331474317557391904421737771073043921970645269542089597979731773648503702868704841073364430415692855717546724618615435573339426156179569967167452848315973174988187609374828049804195765129487206105589281297880978006205934295377053267406244538842850917439517567461736237872246943619457592957990011421297336065899807397771469726120504866372593633749040406609796663717025402134880094428034228535594664968131626016345974380357717590339473317007684176477908216689118452932423003341414549780183259821851840655225709739253002458273898291910440678216870887149560350190586739996629879853487774792317919579141650440805487897477030865070712087883762498657607334044941485457836738330171570635819412740084985560408047330519683348240807942096427518753888911529665552239772392488715462481065978832100562055836960477865790477191838805431925151398195429674168844724618502125040222501011643301681858803669018017769146177971310430164039570827473470118677275696606461102365652876513873570!
 
4190876200697145804692125236821066805337175220605745377557452592208653939853278523841448314026548802309860391087939783218946129582647928430739985554883806198749831633640196211202756086016039171607744078776876219661603702759454887945247605749205543464095883664514960293873244842409803801480566600124415293789831496309554117113888561569494314926134470477513516416560102984058751906208865570183683850791317395702861350821464653600469443279077733978568711404244774089509216727922510660941411716412467443445414001188915966547283773988670739792818897314762082568914041952211779194055311405259158538932388745292324386826830135904886472292289993848482289254307628467614523292519222687689180219788377184005246290896703260524910362136627321135976515358528150143796798116836263053229733971612275184896139539613129329008449214723196703789119820971205922195513915546814704778682373487718946560822811623038853887054357316290622378472322045316639418491798517077275839637525427601452961835674484434498885!
 6988406924685508257651316109259665853395618544561542290482957422747251
2621879974544803139182629522111438189060068320844155808827122861800658905944410880665299278785463449748715867577098342261093659060062717050097248139944414539852275687062609725023022919579927729992184495471569088324255356925665713251566354493183039331751882898644394213897160914262139764680835180969460373487297798414800269996513787044819986616716294925643504041614688682394214445910517503348839586991040520752132901684267316856383753151891833962772406615293362723673056115541822788867351393745450810382610282770612156033090601640416242005137331365457002003319577878502216919170112074608722852376799943191590480651623958062982829452035227119036502426583752512199824089725611711059153935434418985109241404135069047109527514730648502064630431371185922523036941621026392783813435540195800531988645430344745298845640017082732623248838473771603478336326662579219137601422632057648758807935233915527562817942378675243919886800056209434731407685691942327092464101136254795499159351103542747723!
 
43454443636631310499637366165498946549818089271646280504222703822210478406262602748015156737784182131629209529568636861930041786332753076430132308190243597116592516351322551117625891947167343755332093491691057399902096608720766313387151653039178753575542034817451995401301599919333520503257117646010500571611530574866936468267526501431022327176280762024280561743559492789067640895305738489071968122584040039669815562479316156585043604782961704971397764959404751358445856914581957186533573207690355894150776647727994156425641953755517727965486096675384323441855372798887805708540920842219936607611547883597774397984908511480312751237592867932246601885937688972917491803572971856504307350631260352783217496299957022001157223866000467728830189631662734637151868125433561735503412333101756008177714471706565175053852587720690671396654785062638983805263943882180363887689991615386454329321164711463925629922042594508892919282617805319256181483111512590885198697876379136078660799208307!
 814332752984685342485954714853544207940898546931676443201159004047
1266030942746376074187982809857292874382829734306879420308783010740784767155894363033186129183748698373599293267795620690003900348542140553208244771165593739117369452474295075445169488356550100854423929030967163401348223503674045821834526710830392520955478859202303175309815706259592416130388770535449570146586161954289529234209342432075461261173246383180702862172009624828852517861214008242944903162464816939278645210656431141653019224783906038062818006434258491952705341708781231767324026544165240012431457995565227331912056216396141277926932316783631899833106810492890045890947294731794016389385348294079360921757589715698098491612254898203787546124091057862387229987442131738499764391062483957360997512778806

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Uh, I tried factorial(4000) and for display I got:


1828801951514065013314743175573919044217377710730439219706452695420895979797317736485037028687048410733644304156928557175467246186154355733394261561795699671674528483159731749881876093748280498041957651294872061055892812978809780062059342953770532674062445388428509174395175674617362378722469436194575929579900114212973360658998073977714697261205048663725936337490404066097966637170254021348800944280342285355946649681316260163459743803577175903394733170076841764779082166891184529324230033414145497801832598218518406552257097392530024582738982919104406782168708871495603501905867399966298798534877747923179195791416504408054878974770308650707120878837624986576073340449414854578367383301715706358194127400849855604080473305196833482408079420964275187538889115296655522397723924887154624810659788321005620558369604778657904771918388054319251513981954296741688447246185021250402225010116433016818588036690180177691461779713104301640395708274734701186772756966064611023656528765138735704190876200697145804692125236821066805337175220605745377557452592208653939853278523841448314026548802309860391087939783218946129582647928430739985554883806198749831633640196211202756086016039171607744078776876219661603702759454887945247605749205543464095883664514960293873244842409803801480566600124415293789831496309554117113888561569494314926134470477513516416560102984058751906208865570183683850791317395702861350821464653600469443279077733978568711404244774089509216727922510660941411716412467443445414001188915966547283773988670739792818897314762082568914041952211779194055311405259158538932388745292324386826830135904886472292289993848482289254307628467614523292519222687689180219788377184005246290896703260524910362136627321135976515358528150143796798116836263053229733971612275184896139539613129329008449214723196703789119820971205922195513915546814704778682373487718946560822811623038853887054357316290622378472322045316639418491798517077275839637525427601452961835674484434498885698840692468550825765131610925966585339561854456154229048295742274725126218799745448031391826295221114381890600683208441558088271228618006589059444108806652992787854634497487158675770983422610936590600627170500972481399444145398522756870626097250230229195799277299921844954715690883242553569256657132515663544931830393317518828986443942138971609142621397646808351809694603734872977984148002699965137870448199866167162949256435040416146886823942144459105175033488395869910405207521329016842673168563837531518918339627724066152933627236730561155418227888673513937454508103826102827706121560330906016404162420051373313654570020033195778785022169191701120746087228523767999431915904806516239580629828294520352271190365024265837525121998240897256117110591539354344189851092414041350690471095275147306485020646304313711859225230369416210263927838134355401958005319886454303447452988456400170827326232488384737716034783363266625792191376014226320576487588079352339155275628179423786752439198868000562094347314076856919423270924641011362547954991593511035427477234345444363663131049963736616549894654981808927164628050422270382221047840626260274801515673778418213162920952956863686193004178633275307643013230819024359711659251635132255111762589194716734375533209349169105739990209660872076631338715165303917875357554203481745199540130159991933352050325711764601050057161153057486693646826752650143102232717628076202428056174355949278906764089530573848907196812258404003966981556247931615658504360478296170497139776495940475135844585691458195718653357320769035589415077664772799415642564195375551772796548609667538432344185537279888780570854092084221993660761154788359777439798490851148031275123759286793224660188593768897291749180357297185650430735063126035278321749629995702200115722386600046772883018963166273463715186812543356173550341233310175600817771447170656517505385258772069067139665478506263898380526394388218036388768999161538645432932116471146392562992204259450889291928261780531925618148311151259088519869787637913607866079920830781433275298468534248595471485354420794089854693167644320115900404712

and did factorial(6000) and see:


26839997657267395961163166474627355122050186046884725685824261445661070965868578859479409748346329836182703089128852632609939583160469201526637034786976396625075825887529584878861523984702266296018595427551580174654216923424895644549809732165397549500287960097044436776098097112285935902002318300817766074944639865419157280524790653203290253917356133633993978535760253069357555142219669129998317026518032402810751448010557484004254745274140263837210122325107062378927575415179640798325598920907738968963426553833519168033920097139867697345016081563676374441238664213080213666256929097791375199485350231595456497900149202746728755327879812971546373369370677385700341673192285360910112728679385205719710580583641371671892447976818829243817888754721448962887123232268424960754147650482415903026606790

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Joshua D. Drake]

> OK, updated text:
> 
>   --with-openssl  build with OpenSSL support
>   --with-libedit-preferred  prefer Libedit over Libreadline
>   --without-readline  do not use Libreadline/Libedit line editing
>   --without-zlib  do not use Zlib

This all seems kind of extra... Why not just:

--with-libedit  Use libedit instead of readline
--with-readline Use readline instead of libedit (default)
--without-readline Use when readline is not available

Joshua D. Drake



> 
-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl, ODBCng - http://www.commandprompt.com/



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

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> Sorry, I am confused.  If our computational range is that high, why does
> SELECT factorial(4000) and SELECT factorial(6000) produce the same
> number of digits on my screen.

Are you counting correctly?

regression=# select log(factorial(4000));
  log

 12673.2621666764869773
(1 row)

regression=# select log(factorial(6000));
log

 20065.428782473590
(1 row)

regression=# select factorial(4000)
regression-# \g z4000
regression=# select factorial(6000)
regression-# \g z6000
regression=# \q
$ wc z4000 z6000
5 5 38039 z4000
5 5 60215 z6000

The actual representation limit at the moment (with int16 weights in the
storable format) is 10^128K, as you can soon prove with pow():

regression=# select pow(10::numeric, 131071);
<< lots o zeroes >>
regression=# select pow(10::numeric, 131072);
ERROR:  value overflows numeric format

I don't recall what factorial that might correspond to, but it's
considerably above 6000.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> >   --with-libedit-preferred  prefer libedit over readline
> >   --without-readline  do not use Readline
> 
> Possibly
> --without-readline  do not use readline or libedit
> 
> In any case please be consistent about the capitalization ...

OK, updated text:

  --with-openssl  build with OpenSSL support
  --with-libedit-preferred  prefer Libedit over Libreadline
  --without-readline  do not use Libreadline/Libedit line editing
  --without-zlib  do not use Zlib

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 1: 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: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Tom Lane]

Bruce Momjian  writes:
>   --with-libedit-preferred  prefer libedit over readline
>   --without-readline  do not use Readline

Possibly
--without-readline  do not use readline or libedit

In any case please be consistent about the capitalization ...

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > I am confused by your use of the term "dynamic" range.  From what you
> > say above that we are just moving from 1000 to 508 for storage, and that
> > computational range would still be 4096?
> 
> No, computational range would still be on the order of 10^16G ... in the
> computational format, the weight is an int.  The restriction to 1000
> digits was never anything but an artificial limit.  (Of course, you
> might not have the patience to actually do any arithmetic with that many
> digits, but the point is there was a whole lot of headroom before, and
> now there won't be.)

Sorry, I am confused.  If our computational range is that high, why does
SELECT factorial(4000) and SELECT factorial(6000) produce the same
number of digits on my screen.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 1: 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: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > The basic problem is that with two deterministic flags the default
> > values for those flags are unclear.
> 
> That's a really good point ... the only explainable default would be
> that both are --without, which is a crummy default.
> 
> I think the way that Bruce's patch works is fine, only the name of the
> switch needs tweaking ;-)

Already renamed and patch posted:

  --with-bonjour  build with Bonjour support
  --with-openssl  build with OpenSSL support
  --with-libedit-preferred  prefer libedit over readline
  --without-readline  do not use Readline

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 6: explain analyze is your friend

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Bruce Momjian]

Andrew Dunstan wrote:
> >>I trimmed it down to:
> >>  --with-prefer-libedit   prefer libedit over readline
> >
> 
> I think it's ugly. Can't we just say --prefer-libedit ?
> 
> If must be a --with-foo flag, maybe --with-libedit-preferred or 
> --with-libedit-first would be better.

OK, changed:

  --with-bonjour  build with Bonjour support
  --with-openssl  build with OpenSSL support
  --with-libedit-preferred  prefer libedit over readline
  --without-readline  do not use Readline

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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
Index: configure
===
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.462
diff -c -c -r1.462 configure
*** configure   5 Nov 2005 16:42:00 -   1.462
--- configure   2 Dec 2005 18:37:46 -
***
*** 890,895 
--- 890,896 
--with-pam  build with PAM support
--with-bonjour  build with Bonjour support
--with-openssl  build with OpenSSL support
+   --with-libedit-preferred  prefer libedit over readline
--without-readline  do not use Readline
--without-zlib  do not use Zlib
--with-gnu-ld   assume the C compiler uses GNU ld [default=no]
***
*** 3772,3777 
--- 3773,3809 
  
  
  #
+ # Prefer libedit
+ #
+ 
+ 
+ 
+ # Check whether --with-libedit-preferred or --without-libedit-preferred was 
given.
+ if test "${with_libedit_preferred+set}" = set; then
+   withval="$with_libedit_preferred"
+ 
+   case $withval in
+ yes)
+   :
+   ;;
+ no)
+   :
+   ;;
+ *)
+   { { echo "$as_me:$LINENO: error: no argument expected for 
--with-libedit-preferred option" >&5
+ echo "$as_me: error: no argument expected for --with-libedit-preferred 
option" >&2;}
+{ (exit 1); exit 1; }; }
+   ;;
+   esac
+ 
+ else
+   with_libedit_preferred=no
+ 
+ fi;
+ 
+ 
+ 
+ #
  # Readline
  #
  
***
*** 6490,6504 
  
  if test "$with_readline" = yes; then
  
- echo "$as_me:$LINENO: checking for readline" >&5
- echo $ECHO_N "checking for readline... $ECHO_C" >&6
  
  if test "${pgac_cv_check_readline+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
  else
pgac_cv_check_readline=no
  pgac_save_LIBS=$LIBS
! for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
  LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
  cat >conftest.$ac_ext <<_ACEOF
--- 6522,6540 
  
  if test "$with_readline" = yes; then
  
  
  if test "${pgac_cv_check_readline+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
  else
pgac_cv_check_readline=no
  pgac_save_LIBS=$LIBS
! if test x"$with_libedit_preferred" != x"yes"
! then  READLINE_ORDER="-lreadline -ledit"
! else  READLINE_ORDER="-ledit -lreadline"
! fi
! for pgac_rllib in $READLINE_ORDER ; do
!   echo "$as_me:$LINENO: checking for ${pgac_rllib}" >&5
! echo $ECHO_N "checking for ${pgac_rllib}... $ECHO_C" >&6
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
  LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
  cat >conftest.$ac_ext <<_ACEOF
***
*** 6557,6563 
esac
  
pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
!   break 2
  
  else
echo "$as_me: failed program was:" >&5
--- 6593,6599 
esac
  
pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
!   break
  
  else
echo "$as_me: failed program was:" >&5
***
*** 6567,6590 
  rm -f conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
done
  done
  LIBS=$pgac_save_LIBS
  
  fi
  
  if test "$pgac_cv_check_readline" != no ; then
  
  cat >>confdefs.h <<\_ACEOF
  #define HAVE_LIBREADLINE 1
  _ACEOF
  
-   LIBS="$pgac_cv_check_readline $LIBS"
-   echo "$as_me:$LINENO: result: yes ($pgac_cv_check_readline)" >&5
- echo "${ECHO_T}yes ($pgac_cv_check_readline)" >&6
- else
-   echo "$as_me:$LINENO: result: no" >&5
- echo "${ECHO_T}no" >&6
  fi
if test x"$pgac_cv_check_readline" = x"no"; then
  { { echo "$as_me:$LINENO: error: readline library not found
  If you have readline already installed, see config.log for details on the
--- 6603,6631 
  rm -f conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
done
+   if test "$pgac_cv_check_readline" != no ; then
+ echo "$as_me:$LINENO: result: yes ($pgac_cv_check_readline)" >&5
+ echo "${ECHO_T}yes ($pgac_cv_check_readline)" >&6
+ break
+   else
+ echo "$as_me:$LINENO: result: no" >&5
+ echo "${ECHO_T}no" >&6
+   fi
  done
  LIBS=$pgac_save_LIBS
  
  fi
  
  if test "$pgac_cv_check_readline" != no ; then
+   LIBS="$pgac_cv_check_readline $LIBS"
  
  cat >>confdefs.h <<\

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Tom Lane]

Bruce Momjian  writes:
> The basic problem is that with two deterministic flags the default
> values for those flags are unclear.

That's a really good point ... the only explainable default would be
that both are --without, which is a crummy default.

I think the way that Bruce's patch works is fine, only the name of the
switch needs tweaking ;-)

regards, tom lane

---(end of broadcast)---
TIP 1: 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: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Bruce Momjian]

Tom Lane wrote:
> Chris Browne <[EMAIL PROTECTED]> writes:
> > To my mind, giving BIG weight to the opinions of the relatively small
> > set of individuals that manage PostgreSQL packages for the popular
> > distributions of Linux and *BSD seems fairly appropriate.
> 
> The packagers are bright enough to adapt to whatever we do --- it's
> the people who build their own from source that I'm worried about.
> --with-readline has worked fine for libedit users for a long time,
> and suddenly changing its semantics strikes me as a bad idea.
> 
> The other problem with the "let's be deterministic" argument is that
> it rests on a fallacy, which is that configure can reliably tell the
> difference between libreadline and libedit.  Darwin, for example, goes
> to some lengths to confuse matters.
> 
> (I think I'd actually be for the determinism point of view if it could
> provide an #ifdef flag saying which library is in use --- then we could
> fix the write_history return value problem we're seeing on Darwin ---
> but I don't think we can do it short of a behavioral probe during
> configure.)

Let me add one more thing into the mix.  Right now, you have to say
--without-readline if you don't want any command-line editing. 
(Remember, configure will currently fail if it doesn't find readline or
libedit.)  How will we do that if we have separate flags for readline
and libedit?

Right now, --with-readline is on by default, and fails if readline or
libedit can not be found.  If we change to two flags, then we will have
to say --without-readline --with-libedit to get libedit to work, and
--without-readline and --without-libedit to configure for no line
editing capability.  Does anyone want to try to explain that in an email
over and over again for 8.2?  :-)

The basic problem is that with two deterministic flags the default
values for those flags are unclear.  We really want to default to
looking for either of them, but want to the ability to give preference
to one over the other.  Deterministic is great, but how do we do that
with reasonable defaults?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> I am confused by your use of the term "dynamic" range.  From what you
> say above that we are just moving from 1000 to 508 for storage, and that
> computational range would still be 4096?

No, computational range would still be on the order of 10^16G ... in the
computational format, the weight is an int.  The restriction to 1000
digits was never anything but an artificial limit.  (Of course, you
might not have the patience to actually do any arithmetic with that many
digits, but the point is there was a whole lot of headroom before, and
now there won't be.)

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

[PATCHES] unsuscribe pgsql-patches

[Julio César Elizondo]

 
unsuscribe 
pgsql-patches
 
    Julio 
César Elizondo GTI- Adm. Base Datos y SAP  
Distribuidora de Gas Cuyana S.A.Distribuidora de Gas Del Centro 
S.A.   [EMAIL PROTECTED]

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > So we are really decreasing the specified precision from 1000 to 508,
> > and the computational precision from 4096 to 508.
> 
> The internal computational precision isn't any less, the limit is only
> on the result of a function (ie, partial results within one of the
> numeric.c routines could still exceed 10^508).  Not sure how much that
> distinction matters though.

Agreed.

> > Is there any plan to
> > fix the silent overflow problem?  Is that in the patch?  I don't see it.
> 
> It will get fixed before application ;-)
> 
> I haven't reviewed the patch yet; I think the gating factor at this
> point is whether anyone protests losing dynamic range in NUMERIC,
> and we ought to go ahead and ask that.  After that we can look at the
> code more closely.

I am confused by your use of the term "dynamic" range.  From what you
say above that we are just moving from 1000 to 508 for storage, and that
computational range would still be 4096?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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: Don't 'kill -9' the postmaster

[PATCHES] unsuscribe patches

[Julio César Elizondo]

 
    Julio 
César Elizondo GTI- Adm. Base Datos y SAP  
Distribuidora de Gas Cuyana S.A.Distribuidora de Gas Del Centro 
S.A.   [EMAIL PROTECTED]

Re: [PATCHES] Numeric 508 datatype

[Tom Lane]

Bruce Momjian  writes:
> So we are really decreasing the specified precision from 1000 to 508,
> and the computational precision from 4096 to 508.

The internal computational precision isn't any less, the limit is only
on the result of a function (ie, partial results within one of the
numeric.c routines could still exceed 10^508).  Not sure how much that
distinction matters though.

> Is there any plan to
> fix the silent overflow problem?  Is that in the patch?  I don't see it.

It will get fixed before application ;-)

I haven't reviewed the patch yet; I think the gating factor at this
point is whether anyone protests losing dynamic range in NUMERIC,
and we ought to go ahead and ask that.  After that we can look at the
code more closely.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Tom Lane]

Chris Browne <[EMAIL PROTECTED]> writes:
> To my mind, giving BIG weight to the opinions of the relatively small
> set of individuals that manage PostgreSQL packages for the popular
> distributions of Linux and *BSD seems fairly appropriate.

The packagers are bright enough to adapt to whatever we do --- it's
the people who build their own from source that I'm worried about.
--with-readline has worked fine for libedit users for a long time,
and suddenly changing its semantics strikes me as a bad idea.

The other problem with the "let's be deterministic" argument is that
it rests on a fallacy, which is that configure can reliably tell the
difference between libreadline and libedit.  Darwin, for example, goes
to some lengths to confuse matters.

(I think I'd actually be for the determinism point of view if it could
provide an #ifdef flag saying which library is in use --- then we could
fix the write_history return value problem we're seeing on Darwin ---
but I don't think we can do it short of a behavioral probe during
configure.)

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] Case Conversion Fix for MB Chars

[Bruce Momjian]

Volkan YAZICI wrote:
> On 12/1/05, Bruce Momjian  wrote:
> > Where are we on this patch? Is it to be applied?
> 
> After Tom's advice (he was doubtful about the patch), while I was
> thinking about how to improve the spectrum of tests, decided to use
> src/test/mb. In the tests, patch just succeded for unicode and failed
> on big5, euc_cn, euc_jp, euc_kr, euc_tw, mule_internal, sjis
> encodings. Fails' reason can be my wrong configuration too. (I've made
> tests on a both unicode and latin-5 encoded databases.)

Do those encodings even have uppercase letters?

> AFAIC, euc* encodings break latin-n and fixed latin-n encodings break
> euc*. Seems like a deadlock. Furthermore, I'm not aware of the status
> of ICU (will it be applied with 8.2?), thus we can go a way through
> like distributing latin-n fixed PostgreSQL sources/binaries on
> postgresql.org.tr.

People have talked about ICU but I don't know if anyone is working on it
now.

I think the big problem is that while your patch works for some cases,
it fails for others, and there is no good way to know/test which will
work and which will not.  Is that accurate?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 5: don't forget to increase your free space map settings

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Bruce Momjian wrote:
> OK, seems all objections have been dealt with so it goes into the patch
> queue.  I will ask on 'general'.
> 
> The only downside I see is that I can't impress people by doing:
> 
>   SELECT factorial(4000);
> 
> I don't suppose the _impression_ factor is worth two bytes per value. 
> Shame.
> 
> I suppose people wanting to do such manipulations will have to store the
> numbers as text and use a server-side library like perl to do
> calculations.

Oops, I was wrong about this.  The patch changes the maximum _specified_
precision:

  /*
!  * Hardcoded precision limit - arbitrary, but must be small enough 
that
!  * dscale values will fit in 14 bits.
   */
! #define NUMERIC_MAX_PRECISION 1000

  /*
   * Internal limits on the scales chosen for calculation results
--- 15,23 
  #define _PG_NUMERIC_H_

  /*
!  * Hardcoded precision limit - maximum that can fit in Numeric storage
   */
! #define NUMERIC_MAX_PRECISION 508

but in fact, our computational precision is 4096, and we silently
overflow for values greater than that:

test=> create table test(x numeric);
CREATE TABLE
test=> insert into test values (factorial(4000));
INSERT 0 1

The length is 4096 digits, and so is factorial(1) --- clearly wrong.
I now see in the TODO:

* Change NUMERIC to enforce the maximum precision, and increase it

So we are really decreasing the specified precision from 1000 to 508,
and the computational precision from 4096 to 508.  Is there any plan to
fix the silent overflow problem?  Is that in the patch?  I don't see it.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 1: 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: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Chris Browne]

[EMAIL PROTECTED] (Tom Lane) writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> I'm concerned that this still gives nondeterministic behavior.
>> There's no way to say, "I want readline, period" or "I want
>> libedit, period".  I'd prefer simple --with-readline and
>> --with-libedit, giving one turns off the other, giving both is an
>> error.
>
> OTOH that doesn't provide a way to express "I'll take either".
> Given that I'll-take-either has so far satisfied 99.44% of users,
> getting rid of it doesn't seem like the best plan.

I'll bet that for well over 80% of those 99.44% (was this, by any
chance, part of the 80% in the infamous quote "80% of all statistics
quoted to prove a point are made up on the spot"???  :-)), that what
happens is that the satisfied users have taken a prepackaged copy of
PostgreSQL.

On my home installations, for instance, I'm satisfied with whatever
configuration Martin Pitt did when he built Debian packages for
PostgreSQL, and there are doubtless a lot of others being satisfied
identically.

Those that use .rpms that you manage for Red Hat, or that other
packagers manage for Mandriva, SuSE, FreeBSD Ports, and such, fall
into much the same category of "satisfaction" where a lot of the
99.44% are being satisfied by the choices of a set of on the order of
a dozen individuals that do packaging.

Those of us using packages, who are probably quite common, are a big
step indirected from this.  We don't have a reason to prefer
determinism or nondeterminism in this matter; we'll get exactly one
choice, namely the choice that one or another of those ~ dozen people
make.

> It might be possible to set things up so that you can specify "I'll take
> either" by writing both switches, and further that the order in which
> you write the switches determines the preference --- though I'm not
> entirely sure how to do the latter within the autoconf framework.

I'll change hats; in my "overseeing binaries used at Afilias hat," my
vote would be with Peter, for determinism.  I'm not particularly
interested in seeing psql "magically" configure itself to slightly
prefer one editing library over another; I'd be entirely happy with:

 --with-readline
 implying that GNU readline shall be used, and libedit shall not
 --with-editline
 implying that libedit shall be used, and GNU readline shall not

Supposing we were to change to this "deterministic semantic" for 8.2,
I don't see a grand problem, here.  It seems likely to me that it
might confuse someone for all of 5 seconds when ./configure reports
back "Sorry, you don't have readline installed, so --with-readline
won't work!"

In contrast, the nondeterministic approach requires having extra knobs
to fiddle in order to prefer one thing to another.  I'm not sure but
that "configure hints" are as unattractive as "optimizer hints" :-).

To my mind, giving BIG weight to the opinions of the relatively small
set of individuals that manage PostgreSQL packages for the popular
distributions of Linux and *BSD seems fairly appropriate.
-- 
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/advocacy.html
Rules of the Evil Overlord #25.  "No matter how well it would perform,
I  will never  construct any  sort  of machinery  which is  completely
indestructible  except  for   one  small  and  virtually  inaccessible
vulnerable spot." 

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] Numeric 508 datatype

[Bruce Momjian]

Simon Riggs wrote:
> 
> Now we're into 8.2devel mode, its time to submit the previously
> discussed patch that:
> 
> - reduces Numeric storage format by 2 bytes
> - limits scale to +/- 508 decimal places
> 
> This is sufficient to allow Numeric to continue to be used as the
> default numeric representation for all numbers in the parser.
> 
> Passes: make check on cvstip, as well as some tests not in there.
> 
> Code comments explain the new format and consequences.
> 
> As previously agreed, reviewing this is a 2 stage process:
> 1. review/possibly agree OK to commit
> 2. check with everybody on GENERAL that the restriction to 508 is
> acceptable
> 
> Figure there's no point doing (2) until we agree the proposal/code is
> workable.

OK, seems all objections have been dealt with so it goes into the patch
queue.  I will ask on 'general'.

The only downside I see is that I can't impress people by doing:

SELECT factorial(4000);

I don't suppose the _impression_ factor is worth two bytes per value. 
Shame.

I suppose people wanting to do such manipulations will have to store the
numbers as text and use a server-side library like perl to do
calculations.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@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 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] Check for integer overflow in datetime functions

[Joshua D. Drake]

http://projects.commandprompt.com/projects/public/pgsql/browser/trunk/pgsql 



It has the additional advantage over our current CVSweb that it's 
set with tabs to 4 spaces, so it looks just like our code is 
supposed to ...
  




I need to spend some time on it to see if there is a way that I can 
convert more then the whole tree at a time within the same repository. 
Right now we have to convert

the whole thing which takes quite a bit of time.


Oh and don't forget to use the RSS capabilities.



Yes, and I for one love it :-)

Now if I could just access the actual svn repository as well, I'd be
even happier...


We are also happy to provide accounts to those who would like to 
actually use the wiki to discuss specific aspects of the code. This 
would be more for wannabe hacker edibility,

tips, tricks etc...





I have added it to the set of useful links on pgfoundry's front page.


Cool!


Joshua D. Drake



cheers

andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend




--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl - http://www.commandprompt.com/


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] Check for integer overflow in datetime functions

[Andrew Dunstan]

Magnus Hagander wrote:

BTW, has anyone checked Command Prompt's Subversion 
repository?  It's a mirror of our anonymous CVS (AFAICT).  
I'm using it for reading diffs lately, and it's much nicer to 
look at the whole patch as a single diff rather than going a 
single file at a time.


http://projects.commandprompt.com/projects/public/pgsql/browser/trunk/pgsql

It has the additional advantage over our current CVSweb that 
it's set with tabs to 4 spaces, so it looks just like our 
code is supposed to ...
   



Yes, and I for one love it :-)

Now if I could just access the actual svn repository as well, I'd be
even happier...


 



I have added it to the set of useful links on pgfoundry's front page.

cheers

andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Andrew Dunstan]

Tom Lane wrote:


Bruce Momjian  writes:
 


I trimmed it down to:
 --with-prefer-libedit   prefer libedit over readline
   



OK, I can live with that.


 



I think it's ugly. Can't we just say --prefer-libedit ?

If must be a --with-foo flag, maybe --with-libedit-preferred or 
--with-libedit-first would be better.


cheers

andrew

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

  http://archives.postgresql.org

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I'm concerned that this still gives nondeterministic behavior.  There's 
> no way to say, "I want readline, period" or "I want libedit, period".  
> I'd prefer simple --with-readline and --with-libedit, giving one turns 
> off the other, giving both is an error.

OTOH that doesn't provide a way to express "I'll take either".  Given
that I'll-take-either has so far satisfied 99.44% of users, getting rid
of it doesn't seem like the best plan.

It might be possible to set things up so that you can specify "I'll take
either" by writing both switches, and further that the order in which
you write the switches determines the preference --- though I'm not
entirely sure how to do the latter within the autoconf framework.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [PATCHES] TODO item -- Improve psql's handling of multi-line queries

[Andreas Seltenreich]

Bruce Momjian writes:

> Where are we on this patch?  Was it submitted?  Applied?  Just an
> idea?

| This has been saved for the 8.2 release:
| 
|   http://momjian.postgresql.org/cgi-bin/pgpatches_hold

I tested it with 8.1RC1 and noticed the inconsistency with the \edit
command. I guess one would at least need to change do_edit to modify
the newly introduced history_buffer instead of the history itself.

But I'm not sure why there is a need for a history_buffer at all,
couldn't one use the query_buffer instead? (Sergey?)

regards,
Andreas
-- 

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] Case Conversion Fix for MB Chars

[Volkan YAZICI]

On 12/1/05, Bruce Momjian  wrote:
> Where are we on this patch? Is it to be applied?

After Tom's advice (he was doubtful about the patch), while I was
thinking about how to improve the spectrum of tests, decided to use
src/test/mb. In the tests, patch just succeded for unicode and failed
on big5, euc_cn, euc_jp, euc_kr, euc_tw, mule_internal, sjis
encodings. Fails' reason can be my wrong configuration too. (I've made
tests on a both unicode and latin-5 encoded databases.)

AFAIC, euc* encodings break latin-n and fixed latin-n encodings break
euc*. Seems like a deadlock. Furthermore, I'm not aware of the status
of ICU (will it be applied with 8.2?), thus we can go a way through
like distributing latin-n fixed PostgreSQL sources/binaries on
postgresql.org.tr.


Regards.

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

Re: [PATCHES] Numeric 508 datatype

[Simon Riggs]

On Thu, 2005-12-01 at 23:34 -0500, Bruce Momjian wrote:
> Where are we on this patch?  It is ready for the patch queue?

It's good to be applied, AFAIK.

> Simon Riggs wrote:
> > As previously agreed, reviewing this is a 2 stage process:
> > 1. review/possibly agree OK to commit
> > 2. check with everybody on GENERAL that the restriction to 508 is
> > acceptable
> > 
> > Figure there's no point doing (2) until we agree the proposal/code is
> > workable.

I was hoping you'd give me a "this looks good enough to apply"
thumbs-up, then I'll ask for comments via a Weekly News item.

If I ask for comments and then it is technically rejected we would be
wasting everybody's time.

Best Regards, Simon Riggs


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?

[Peter Eisentraut]

Bruce Momjian wrote:
> I trimmed it down to:
>
>   --with-bonjour  build with Bonjour support
>   --with-openssl  build with OpenSSL support
>   --with-prefer-libedit   prefer libedit over readline
>   --without-readline  do not use Readline
>   --without-zlib  do not use Zlib

I'm concerned that this still gives nondeterministic behavior.  There's 
no way to say, "I want readline, period" or "I want libedit, period".  
I'd prefer simple --with-readline and --with-libedit, giving one turns 
off the other, giving both is an error.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

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