On Fri, 2002-08-09 at 06:07, Lamar Owen wrote:
On Thursday 08 August 2002 05:36 pm, Nigel J. Andrews wrote:
Matt Kirkwood wrote:
I just spent some of the morning helping a customer build Pg 7.2.1 from
source in order to get Linux largefile support in pg_dump etc. They
possibly would
On Thu, Aug 08, 2002 at 11:19:04PM +0200, Peter Eisentraut wrote:
It seems we need a smart plan for handling the decimal point vs. comma
issue. Observe: (lc_numeric = de_DE)
^^
It seems like hellish toy... :-)
Karel
--
Karel Zak [EMAIL PROTECTED]
Attached is a revised version of my previous
ON COMMIT DROP
patch. This patch implements:
ON COMMIT { DROP | PRESERVE ROWS | DELETE ROWS }
The latter two are SQL99.
Sample usage:
---
template1=# begin;
BEGIN
template1=# create temp table a (a int) on commit drop;
CREATE
template1=# create
On Fri, 9 Aug 2002, Helge Bahmann wrote:
As far as I can make out from the libc docs, largefile support is
automatic if the macro _GNU_SOURCE is defined and the kernel supports
large files.
Is that a correct understanding? or do I actually need to do something
special to ensure that
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
If you apply the pg_stat_reset() function patch you get this regression
failure. Is this because it's returning a bool I guess? Shall I just fix
the regression test to exclude this function?
No, you should fix the function definition. The
Gavin Sherry [EMAIL PROTECTED] writes:
template1=# create temp table a (a int) on commit drop;
ERROR: You must be inside a transaction to use ON COMMIT
Surely that's only for ON COMMIT DROP, if you intend to offer the
others?
regards, tom lane
Fixed very stupid but important bug: mixing calls of some founctions from
contrib/tsearch and contrib/ltree :)
--
Teodor Sigaev
[EMAIL PROTECTED]
patch_ltree.gz
Description: application/gzip
---(end of broadcast)---
TIP 6: Have you searched
Florian Weimer [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
Thomas can correct me if I'm mistaken, but I believe these changes apply
to the new integer datetime code
No, it's possible to crash the backend in 7.2, too.
And 7.2.1, of course.
Let me ask again: Do you plan
Hi Florian,
Is it possible to crash a 7.2.1 backend without having an entry in the
pg_hba.conf file?
i.e. Is every PostgreSQL 7.2.1 installation around vulnerable to a
remote DoS (or worse) from any user anywhere, at this moment in time?
Regards and best wishes,
Justin Clift
Florian Weimer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Moved from
Re: [PATCHES] small psql patch - show Schema name for \dt \dv \dS)
I need something other than RelationIsVisible for psql for the case
when someone says \d foo - I need to be able to decide which
foo table I should display:
Hi, We have a problem with lower() function working differently for two
different data types
table: yuva_test
column_name data_type
yt_name1varchar(255)
yt_name2char(1)
The data is
yt_name1yt_name2
yuvaF
bharat F
1234556 F
234 F
etc.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here's my thoughts on the matter:
More than one period throws an error (something pleasant, mentioning
that we do not quite support cross-database queries yet).
I'll assume we are switching to the explicit wildcard system for this.
(I think the
Greg Sabino Mullane wrote:
At any rate, I will play with the RelationIsVisible stuff when somebody
writes a SQL interface to it (or I write it myself, but that will take
quite a long time :)
Looks like Tom just committed this; see:
Joe Conway writes:
3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
composite type, e.g.:
Forgive this blunt question, but: Why?
Of course I can see the answer, it's convenient, but wouldn't the system
be more consistent overall if all functions and types are
Peter Eisentraut wrote:
Joe Conway writes:
3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
composite type, e.g.:
Forgive this blunt question, but: Why?
Now's a *great* time for a blunt question because I haven't started
actively working on this yet. Much better
I think it buys the same as SERIAL does for sequences.
Is it likely to have more than one function using a complex type like
that? If not, then allowing it's creation (not enforcing) could be
useful.
On Fri, 2002-08-09 at 19:03, Joe Conway wrote:
Peter Eisentraut wrote:
Joe Conway writes:
Rod Taylor wrote:
I think it buys the same as SERIAL does for sequences.
That's a great analogy.
Is it likely to have more than one function using a complex type like
that? If not, then allowing it's creation (not enforcing) could be
useful.
That's what I was thinking. In cases where you
-Original Message-
From: Joe Conway [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 09, 2002 4:04 PM
To: Peter Eisentraut
Cc: pgsql-hackers
Subject: Re: [HACKERS] Proposal: stand-alone composite types
Peter Eisentraut wrote:
Joe Conway writes:
3. Modify CREATE FUNCTION to
On Fri, 9 Aug 2002, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
template1=# create temp table a (a int) on commit drop;
ERROR: You must be inside a transaction to use ON COMMIT
Surely that's only for ON COMMIT DROP, if you intend to offer the
others?
I should have provided
Is it likely to have more than one function using a complex type like
that? If not, then allowing it's creation (not enforcing) could be
useful.
That's what I was thinking. In cases where you want to use the type for
several functions, use CREATE TYPE. If you only need the type for
Thank you, we figured out that, the query with lower() is taking too long
and we thought it is having some problem. The actual table in our database
has more than 10 million rows and query is taking too long.
Thanks
Yuva
-Original Message-
From: Yuva Chandolu
Sent: Friday, August 09,
Hi,
We recently put up a new 7.2.1 installation on Solaris 8 that serves a
24x7 e-commerce site. The system seems to run pretty well most of the
time but we see a consistent form of performance anomaly.
Watching pg_stat_activity the system spends most of it's time running
smoothly with queries
That's what I was thinking. In cases where you want to use the type for
several functions, use CREATE TYPE. If you only need the type for one
function, let the function creation process manage it for you.
It would be nice then to have some mechanism for converting the
automatic type to a
Thomas Lockhart wrote:
That's what I was thinking. In cases where you want to use the type for
several functions, use CREATE TYPE. If you only need the type for one
function, let the function creation process manage it for you.
It would be nice then to have some mechanism for converting the
Tom Lane wrote:
J. R. Nield [EMAIL PROTECTED] writes:
Uh, why? Why not just force a checkpoint and remember the exact
location of the checkpoint within the current log file?
If I do a backup with PITR and save it to tape, I need to be able to
restore it even if my machine is destroyed
Thomas, would you remind me of the concusions because I thought everyone
involved felt that it should be an initdb-only option, but I still see
it in CVS.
---
Thomas Lockhart wrote:
Thomas, have you commented on the
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Teodor Sigaev wrote:
Fixed very stupid but
Thomas, would you remind me of the concusions because I thought everyone
involved felt that it should be an initdb-only option, but I still see
it in CVS.
?? Concussions as in brain bruises? ;)
I'm not sure I understand the question. I assume that we are talking
about the WAL log location
OK, let's get started updating all our db access routines. We only have
22 days left until beta.
---
Joe Conway wrote:
Greg Sabino Mullane wrote:
At any rate, I will play with the RelationIsVisible stuff when somebody
Joe Conway wrote:
Thomas Lockhart wrote:
That's what I was thinking. In cases where you want to use the type for
several functions, use CREATE TYPE. If you only need the type for one
function, let the function creation process manage it for you.
It would be nice then to have some
Thomas Lockhart wrote:
Thomas, would you remind me of the concusions because I thought everyone
involved felt that it should be an initdb-only option, but I still see
it in CVS.
?? Concussions as in brain bruises? ;)
Uh, conclusions. Sorry. New keyboard desk in new house. :-)
I'm
Greg Sabino Mullane [EMAIL PROTECTED] writes:
we'd write something like
select ... from pg_class p, ...
where relname like 'foo%' and pg_relation_is_visible(p.oid) and ...
I see what you are saying, and this is fine for those cases in which the user
has supplied the schema, but I don't see
Peter Eisentraut [EMAIL PROTECTED] writes:
Joe Conway writes:
3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
composite type, e.g.:
Forgive this blunt question, but: Why?
Of course I can see the answer, it's convenient, but wouldn't the system
be more consistent
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Here's my thoughts on the matter:
More than one period throws an error (something pleasant, mentioning
that we do not quite support cross-database queries yet).
The just-committed implementation doesn't throw an error, but silently
discards name
Joe Conway wrote:
more work than I had time for when I wrote the current replace(). But as
I said, if there is support for getting this into the backend, I'll add
it to my todo list:
- Create new backend function replace()
- Either create new backend functions, or merge into existing
Tom Lane wrote:
I was wondering about that too, in particular: what name are you going
to give to the implicit type, and what if it conflicts?
The already-accepted mechanism for anonymous function-result types for
RECORD functions doesn't have that problem, because it has no need to
create
Gavin Sherry [EMAIL PROTECTED] writes:
As for your question (and, perhaps, SQL99) I don't seen how it makes any
sense to specify ON COMMIT outside of a transaction block.
Surely it does.
CREATE TEMP TABLE foo(...) ON COMMIT DELETE ROWS;
BEGIN;
insert some rows in foo;
Lamar Owen wrote:
And you added this by doing what, exactly? I'm not familiar with pg_dump
largefile support as a standalone feature.
Enabling largefile support for the utilities was accomplished by :
CFLAGS=-O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ./configure ...
It seemed to me
Ralph Graulich wrote:
Hi,
just my two cents worth: I like having the files sized in a way I can
handle them easily with any UNIX tool on nearly any system. No matter
wether I want to cp, tar, dump, dd, cat or gzip the file: Just keep it at
a maximum size below any limits, handy for handling.
39 matches
Mail list logo
