Tom Lane wrote:
Justin Clift <[EMAIL PROTECTED]> writes:
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
This question has been touched on before, but I guess it's time to face
i
Joe Conway <[EMAIL PROTECTED]> writes:
> In addition to the ecpg warnings mentioned by Tom, I'm also seeing
> compile warnings wrt plpython:
> make[3]: Entering directory `/opt/src/pgsql-cvs/pgsql-7.5/src/pl/plpython'
> gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
> -Wmissing-decla
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
In file included from /usr/include/python2.3/Python.h:8,
from plpython.c:58:
/usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from /usr/include/stdio.h:28,
from ..
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
Is column comment in the standard? If not, we cannot of course add it...
Chris
---(end of broadcast)--
hi
,
I am on a mission to simply keep a starving project off the ground by updating an old
mysql->pgsql perl conversion script which does its conversion very differently from
the one under contrib/. There is an old link to
http://www.rot13.org/~dpavlin/sql.html
on techdocs under the section
Co
Hi Tom,
As requested - although the results are all over the place... :-(
One interesting factor in these tests is that the max tps without
the new code was 74.7, with the new code, 85.8.
This is a Sony Laptop, slow IDE disk, Fedora Core 2
[EMAIL PROTECTED] pgsql-HEAD]$ uname -a
Linux localhost.loc
On Thu, Jul 01, 2004 at 12:21:55AM -0400, Tom Lane wrote:
> I was all set to launch into a diatribe about the half dozen performance
> issues I think we *must* fix in the new nested-transactions code,
I completely agree, of course.
> This brought me up short. I sure as heck do not see anything i
On Thu, 1 Jul 2004, Justin Clift wrote:
> but we found it useful. It adds the column comments to the
> information_schema.columns view.
Doesn't the specification say exactly what columns should exist?
Lots of things in the old system tables are not visible in the
information_schema because of
I was all set to launch into a diatribe about the half dozen performance
issues I think we *must* fix in the new nested-transactions code, and
thought I'd back it up by citing some pgbench numbers. So I ran pgbench
runs using yesterday's CVS tip and current. I had to fix a small memory
leak befor
In addition to the ecpg warnings mentioned by Tom, I'm also seeing
compile warnings wrt plpython:
make[3]: Entering directory `/opt/src/pgsql-cvs/pgsql-7.5/src/pl/plpython'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -fpic -I. -I/usr/include/python2.3
-I../
Hi all,
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
Hope it's useful.
:-)
Regards and best wishes,
Justin Clift
*** information_schema.sql.orig 2004-07-01 11:59:26.0
Seeing how small storage for a number type is compared to a text type,
and seeing how they tend to be queried on a lot, shouldn't it be
reasonable for the default stats number for numerics to be 100 instead
of 10?
---(end of broadcast)---
TIP 6: H
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Jaime Casanova) would write:
> Can anyone tell me if postgresql has problems with xeon processors?
>
> If so, there is any fix or project of fix it?
Well, there's a known issue that IA-32 systems with more than 4GB of
memory use an extensi
I'm seeing this:
make[4]: Entering directory `/home/postgres/pgsql/src/interfaces/ecpg/ecpglib'
...
gcc -O1 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations
-fpic -DFRONTEND -I../../../../src/interfaces/ecpg/include
-I../../../../src/interfaces/libpq -I../../../../src/p
You are right! (goes away to sign up)
Merlin Moncure wrote:
p.s. this probably belongs on win32 hackers list.
Merlin
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datat
> Does the win32 build have a pg_tablespace table? are there any rows in
> it?
>
> Was thinking the combination of the two queries would be able to
> determine table space support in some fashion:
>
> select * from pg_class where relnamespace = (select oid from
> pg_namespace where nspname = 'pg
On Wed, 2004-06-30 at 11:16, Merlin Moncure wrote:
> > In phpPgAdmin, I need to know if the backend supports tablespaces or
> > not. What is the most reliable way of detecting that the backend is
> the
> > win32 native version and hence does not support tablespaces? Version
> > string info?
> >
On Tue, Jun 29, 2004 at 07:23:45PM +0800, Christopher Kings-Lynne wrote:
> I'm a PostgreSQL developer and I would like to see an SQL99 recursive
> queries feature in PostgreSQL.
Me too, on bot parts.
> I'm not a committer myself, so I think I should explain how things work.
> We're unlike othe
So it can't be compiled by other compiler? Say Digital Mars or some
Microsoft or Borland compiler?
Nope. It needs the GNU tool set.
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [
On Wed, Jun 30, 2004 at 11:16:15AM -0400, Merlin Moncure wrote:
> > In phpPgAdmin, I need to know if the backend supports tablespaces or
> > not. What is the most reliable way of detecting that the backend is
> > the win32 native version and hence does not support tablespaces?
> > Version string i
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> For the past few days I have experienced compile failure with CVS HEAD
>> on win32.
>> The culprit is src/port/pipe.c which uses ereport() when it only
>> #includes "c.h".
> Try replacing "c.h" with "postgres.h". I fixed that on the win32
> binaries
> In phpPgAdmin, I need to know if the backend supports tablespaces or
> not. What is the most reliable way of detecting that the backend is
the
> win32 native version and hence does not support tablespaces? Version
> string info?
>
> Or alternatively, what is the most direct way of detecting it
In phpPgAdmin, I need to know if the backend supports tablespaces or
not. What is the most reliable way of detecting that the backend is the
win32 native version and hence does not support tablespaces? Version
string info?
Or alternatively, what is the most direct way of detecting its presenc
[ moving thread to a more appropriate list ]
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> select 'GRANT EXECUTE ON ' || 1142::regprocedure;
>> ERROR: array value must start with "{" or dimension information
>>
>> BTW, it seems like there's something pretty broken here. How did
>>
> For the past few days I have experienced compile failure with CVS HEAD
> on win32.
> The culprit is src/port/pipe.c which uses ereport() when it only
> #includes "c.h".
Try replacing "c.h" with "postgres.h". I fixed that on the win32
binaries and forgot to mention it.
p.s. this probably belong
> -Original Message-
> From: Andrew Overholt [mailto:[EMAIL PROTECTED]
> Sent: 28 June 2004 16:45
> To: jacob koehler (RRes-Roth)
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alexander Rüegg
> Subject: Re: recursive SQL
>
>
> * jacob koehler (RRes-Roth) <[EMAIL PROTECTED]>
> [2004-06-2
For the past few days I have experienced compile failure with CVS HEAD
on win32.
The culprit is src/port/pipe.c which uses ereport() when it only
#includes "c.h".
I cured the error by #including "postgres.h" - but after a bit of
thought suspect that "utils/elog.h" is all that is necessary!
Is
27 matches
Mail list logo
