On Mon, Nov 13, 2000 at 09:58:30AM +0100, Zeugswetter Andreas SB wrote:
because as said, it can be any other language besides C and also
the 'AS file' is weird.
This is interesting. It allows us to control the default behavour of
"C". I would vote to default to 7.0-style when no
We need the 7.0 style for compatibility with other DB's. Postgres was
"the" pioneer in this area, but similar functionality is now available in other
DB's.
Could you explain? PostgreSQL cant be compatible in C level, why
the SQL compatibility? (I mean the LANGUAGE 'C' specifically)
On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
We need the 7.0 style for compatibility with other DB's. Postgres was
"the" pioneer in this area, but similar functionality is now available in other
DB's.
Could you explain? PostgreSQL cant be compatible in C
'Marko Kreen' wrote:
On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
We need the 7.0 style for compatibility with other DB's. Postgres was
"the" pioneer in this area, but similar functionality is now available in
other DB's.
Could you explain?
mlw [EMAIL PROTECTED] writes:
I'm not sure what "NewC" is, nor do I understand what problem it is
attempting to fix.
I haven't gotten around to updating the main documentation yet (my bad)
but the design document about the fmgr rewrite is in current sources
as src/backend/utils/fmgr/README ---
At 01:53 PM 11/15/00 -0500, markw wrote:
I'd rather not pollute the application's SQL with postgres-isms. Not that I
don't love postgres, but there are always critics looking for a reason to use
Oracle or (gasp) MS-SQL.
Define some global variable with the name of the database being run
I am just suggesting that instead of flushing the log on every
transaction end, just do it every X seconds.
Or maybe more practical is, when the log buffer fills.
And of course during checkpoints.
Also before backend's going to write dirty buffer from pool
to system cache - changes must
One question:
will Postgres 7.1 be able to do offline backups?
--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-
Martín Marqués email: [EMAIL PROTECTED]
Santa Fe - Argentina
Peter Eisentraut [EMAIL PROTECTED] writes:
To start with, what do we need libtermcap and libcurses for? Readline
requires one or the other, but not both. Anything else?
I think that psql once required these. It probably does not anymore
(except indirectly via readline). There's certainly
Peter Eisentraut [EMAIL PROTECTED] writes:
Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
PG_GETARG_INT32 et al. Inconsistency everywhere.
The original convention was
At 23:42 15/11/00 -0500, Bruce Momjian wrote:
To answer another misconception that I saw in this thread:
: The old language names "internal" and "C" will continue to refer to
: functions with the old calling convention. We should deprecate
: old-style functions because of their portability
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.
Directory was what I had in mind too, but I'm not sure what Bruce
actually did
Andrew Snow [EMAIL PROTECTED] writes:
Here's a simpler script which reproduces the bug:
Well, after looking at this some more, I'm not convinced it's a bug;
or at least, if it's a bug it's one that can't be fixed without a
fundamental redefinition of rules/views. Boiled down, here's what
you
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The default path
*must* be determined at compile time, or clients and servers will be
unable to find each other.
The only difference
On Wed, 15 Nov 2000, carl garland wrote:
perhaps why, even at 5 clients, the page views he shows never went
significantly above 10/sec?
I think alot of it has to do with the web server/db setup not pg. They are
using Apache/PHP and looking at their code every page has the additional
Peter Eisentraut [EMAIL PROTECTED] writes:
#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(defpath), (port))
and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The
* Peter Eisentraut [EMAIL PROTECTED] [001115 08:15] wrote:
I couldn't say I like these options, because they seem arbitrary, but
given that it only affects the 0 univel users and the 3 bsdi users left
(freebsd will be fixed), I wouldn't make a fuzz.
BSDi still has a market niche, and they
On Wed, 15 Nov 2000, carl garland wrote:
# perhaps why, even at 5 clients, the page views he shows never went
# significantly above 10/sec?
#
# I think alot of it has to do with the web server/db setup not pg. They are
# using Apache/PHP and looking at their code every page has the
* Peter Eisentraut [EMAIL PROTECTED] [001115 13:11]:
Larry Rosenman writes:
syntax is lexically compatible with the syntax of the SET command.
Therefore you can't have "funny" characters in 'value' unless
single-quoted.
I added period(.), hyphen(-), and underscore(_).
Probably
Here is one with a stray character removed.
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.4
diff -c -r1.4 guc-file.l
***
So Sun has pulled another one on us. Not sure which versions of Solaris
this affects, but some have libncurses and libtermcap with overlapping
symbols of different sizes. This leads to a bunch of complaints every
time 'ld' is run; perhaps it could also lead to busted executables.
(Via a
Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
PG_GETARG_INT32 et al. Inconsistency everywhere.
The C standard has things like int32_t, but technically there's no
Peter Eisentraut [EMAIL PROTECTED] writes:
Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
PG_GETARG_INT32 et al. Inconsistency everywhere.
The original
Bruce Momjian [EMAIL PROTECTED] writes:
I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you want
Bruce Momjian [EMAIL PROTECTED] writes:
I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you
Earlier, Vadim was talking about arranging to share fsyncs of the WAL
log file across transactions (after writing your commit record to the
log, sleep a few milliseconds to see if anyone else fsyncs before you
do; if not, issue the fsync yourself). That would offer less-than-
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The default path
*must* be determined at compile time, or clients and servers will be
unable to find each other.
The only
* Peter Eisentraut [EMAIL PROTECTED] [001115 08:15] wrote:
I couldn't say I like these options, because they seem arbitrary, but
given that it only affects the 0 univel users and the 3 bsdi users left
(freebsd will be fixed), I wouldn't make a fuzz.
BSDi still has a market niche, and
[ Charset ISO-8859-1 unsupported, converting... ]
Earlier, Vadim was talking about arranging to share fsyncs of the WAL
log file across transactions (after writing your commit record to the
log, sleep a few milliseconds to see if anyone else fsyncs before you
do; if not, issue the fsync
Applied.
* Peter Eisentraut [EMAIL PROTECTED] [001113 23:52]:
Okay, but you can't make these options PGC_SIGHUP unless you make sure to
close and re-open the syslog channel whenever these options
change. Probably ought to be PGC_POSTMASTER.
Here is a patch to change to
Sorry, this was not applied. Seems it is already fixed.
* Peter Eisentraut [EMAIL PROTECTED] [001113 23:52]:
Okay, but you can't make these options PGC_SIGHUP unless you make sure to
close and re-open the syslog channel whenever these options
change. Probably ought to be
Applied.
Here is one with a stray character removed.
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.4
diff -c -r1.4
On Lun 13 Nov 2000 13:22, Robert D. Nelson wrote:
Still...Regardless of what database they're running, either their
abstraction layer is shit or their queries really need optimized. Is that
perhaps why, even at 5 clients, the page views he shows never went
significantly above 10/sec?
In the
markw [EMAIL PROTECTED] writes:
Just a question, however, what is the feeling about the way statistics are
currently being calculated?
They suck, no question about it ;-)
My feeling is that some sort of windowing
algorithm be used to normalize the statistics to the majority of the entries
perhaps why, even at 5 clients, the page views he shows never went
significantly above 10/sec?
I think alot of it has to do with the web server/db setup not pg. They are
using Apache/PHP and looking at their code every page has the additional
overhead of making the db connection. Now if
At 09:27 AM 11/15/00 -0800, Tom Samplonius wrote:
AOLServer isn't the only system that can pool database connections, so
can servlets/JSP, ColdFusion, ASP, etc. No doubt AOLServer would be more
widely accepted if it used something other than TCL.
There are two separate modules that support
Andrew McMillan wrote:
mlw wrote:
My music database has 50,000 arises and 210,000 albums. Many artists
have only one or 2 entries in the albums table (for the youngsters, CD
table ;-). About 34,000 have the integer key for "Various Artists" as
their artist entry, and another few
37 matches
Mail list logo
