On 7/28/05, Neil Conway [EMAIL PROTECTED] wrote:
Tom Lane wrote: How about list_append_distinct and list_concat_distinct?Those names are fine with me.
list_append_unique and list_concat_unique might be a little clearer, unless you want to retain the sqlism of distinct.
On 5/3/05, Dave Held [EMAIL PROTECTED] wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 12:39 PM
To: Heikki Linnakangas
Cc: Hannu Krosing; Neil Conway; Oliver Jowett;
[EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
On 10/15/2004 1:02 PM Nurlan M. Mukhanov could be overheard saying::
Hello!
I wrote this css file 2 years ago. It's very useful when using docs.
Can you add it in mainstream?
You might want to consider revising it to include fallbacks to standards
(or common aliases) such as Helvetica, Times,
On 10/12/2004 4:02 PM Tom Lane could be overheard saying::
Marcos A Vaz Salles [EMAIL PROTECTED] writes:
In order to make index selection possible, we
have extended the PostgreSQL DBMS to allow the simulation of
hypothetical indexes. We believe these server extensions may be of
value for
The 7.4 release increased the maximum length for column and table
identifiers to 64 characters. Are there any plans to increase the
maximum length out to the SQL spec of 128 characters? I remembered
some performance penalties for the longer name lengths for hash joins
but I don't know if
Andreas Pflug wrote:
Simon Riggs wrote:
ISTM - my summary would be
1. We seem to agree we should support SAVEPOINTs
2. We seem to agree that BEGIN/COMMIT should stay unchanged...
With savepoints, it looks pretty strange:
BEGIN;
SAVEPOINT x1;
INSERT INTO ...;
SAVEPOINT x2;
Scott Marlowe wrote:
On Tue, 2004-07-06 at 23:36, Greg Stark wrote:
Scott Marlowe [EMAIL PROTECTED] writes:
Why not rollback all or commit all?
I really really don't like subbegin and subcommit. I get the feeling
they'll cause more problems we haven't foreseen yet, but I can't put my
Tom Lane wrote:
Mike Benoit [EMAIL PROTECTED] writes:
On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
But then we're back to
Alvaro Herrera wrote:
On Fri, Jul 02, 2004 at 01:14:25PM -0400, Merlin Moncure wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
Question: with the new syntax, would issuing a BEGIN
Alvaro Herrera wrote:
On Fri, Jul 02, 2004 at 01:37:46PM -0500, Thomas Swan wrote:
Alvaro Herrera wrote:
Then again, since a statement is always transactionally wrapped, would
it be required to always issue SUBBEGIN if issued from within a
function? This would address my concern
Is there going to be an option to abort the complete transaction without
knowing how deep you are? Perhaps something like ABORT ALL.
The reason I suggest this, is that I can foresee an application or user
leaving nested transactions open inadvertently, or not knowing how
deeply nested they
sdv mailer wrote:
Hi Bruce,
Sorry for the confusion because Rod asked a question
and I answered too quickly. This is what I mean.
15x Slower:
---
Client --TCP-- PgPool --UNIX-- PostgreSQL
Client --TCP-- PgPool --TCP-- PostgreSQL
5x Faster:
--
Client --UNIX-- PgPool --UNIX--
Fabien COELHO wrote:
Dear hackers,
It seems to me that the current default setup for a new database which is
given to some user is not consistent (createdb -O calvin foo or
CREATE DATABASE foo WITH OWNER calvin).
Indeed, although the database belongs to the owner, the public schema
still
Fabien COELHO wrote:
Dear Thomas,
* create the database with the new owner specified.
-- As a superuser in the newly created database
update pg_am set amowner = {userid}
update pg_class set relowner = {userid}
You don't want to update ownership of tables in system schemas.
AFAICS, any
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
You don't want to update ownership of tables in system schemas.
AFAICS, any changes they make are localized to their database not the
whole database system.
A database owner who is not a superuser
Bruce Momjian wrote:
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to ask the question.
MySQL became popular at my university when the students discovered they
could install it on their personal computers. Just the exposure for
Bruce Momjian wrote:
I looked into this and I see a number of cases where pg_autovacuum calls
send_query(), but doesn't test for a NULL return from the function.
Matthew, would you look into this and submit a patch? Thanks.
Should pg_autovacuum be vacuuming temporary tables? Secondly, why
quote who=Andrew Hammond
Tom Lane wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
I've attached a patch for pg_ctl which integrates the Apache project's
rotatelogs for logging.
Why bother? You just pipe pg_ctl's output to rotatelogs and you're done.
It's not difficult to do, once you know
quote who=Peter Eisentraut
Thomas Swan wrote:
Is there a reason the postmasters cannot just close/reopen-recreate
the log file when a SIGHUP or other signal is issued like apache?
Yes, because there is no log file. The postmaster writes to stdout or
stderr.
Ok, my misunderstanding
quote who=Bruce Momjian
The only other idea I can think of is to create a new pg_path.conf file.
It would have the same format as postgresql.conf, but contain
information about /data location, config file location, and perhaps
pg_xlog location.
The file would be created by special flags to
Bruce Momjian wrote:
Thomas Swan wrote:
I thought the idea was to *reduce* the number of config files and provide
a unified configuration file. Ideally, the unified configuration file
could eliminate the need for environment variables altogether.
If I understand this correctly, the author
[EMAIL PROTECTED] wrote:
I just had a thought about this: seems like a big part of the objection
is the risk of specifying -C and -D that don't go together. Well, what
if they were the same switch? Consider the following simplification of
the proposed patch:
I was really excited about
Bruce Momjian wrote:
pgman wrote:
Josh Berkus wrote:
Tom,
I don't think it's an open-and-shut decision as to whether people
actually *need* to do session kills (as opposed to query/transaction
kills). The arguments presented so far are not convincing to my mind,
certainly not
quote who=Dustin Sallings
On Mar 25, 2004, at 1:21, Neil Conway wrote:
I think the lack of good Win32 support (unless rectified before the
release of 7.5) is a pretty major problem with Arch -- that alone
might be sufficient to prevent us from adopting it.
I don't do Windows, but my
quote who=Andrew Dunstan
Karel Zak wrote:
The problem with CSV is that it will correctly work with new protocol
only. Because old versions of clients are newline sensitive. And CSV
can contains newline in by quotation marks defined attributes:
John, Smith, The White House
1600
quote who=Tom Lane
My feeling is that we want people to consider these projects as closely
tied to the Postgres community and so postgresql.something is just right.
I can see there are different opinions out there though...
foundry.postgresql.org?
---(end of
quote who=Tom Lane
Bill Moran [EMAIL PROTECTED] writes:
Am I missing something here?
Hmm. It seems like int-to-bit casting ought to be aware of the
bit-width one is casting to, and take that number of bits from
the right end of the integer. This would make it be the inverse
of the other
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
My feeling is that we need not support tablespaces on OS's without
symlinks.
To create symlinked directories on Win2k NTFS
Bruce Momjian wrote:
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
I am expecting to hear some bleating about this from people whose
preferred platforms don't support symlinks ;-). However, if we don't
Well, one option would be to
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
The advantage of symlinks is that an administrator could see how things
are laid out from the command line.
That's a poor reason to require symlinks. The administrator can just as
easily open up psql
Robert Treat wrote:
On Thu, 2004-02-05 at 16:51, Josh Berkus wrote:
Tom,
Yes we do: there's a lock.
Sorry, bad test. Forget I said anything.
Personally, I would like to have the 2nd vacuum error out instead of blocking.
However, I'll bet that a lot of people won't agree with
Marc G. Fournier wrote:
On Fri, 16 Jan 2004, Michael Glaesemann wrote:
On Jan 16, 2004, at 9:39 PM, Jeff Davis wrote:
I can't point to any OSS project that completely renames its parts. I
think a shortened version of the name makes sense (in this case
postgres works well, but so does
Marc G. Fournier wrote:
On Fri, 16 Jan 2004, Thomas Swan wrote:
Perhaps postgresd, postgresqld, or pg_daemon might be a little more
intuitive?
I think at this late stage in the game (almost 10 years), changing could
be a bit difficult and confusing, no? :) I'd go with something like
Bruce Momjian wrote:
Alex J. Avriette wrote:
On Sun, Jan 04, 2004 at 07:59:02PM -0600, D. Dante Lorenso wrote:
Anything other than simple, short commands is a waste, IMHO. I can easily
remember SHOW DATABASES and SHOW TABLES and DESC table, because they
reflect
my intensions directly
available for double the existing database size for conversion
on that mount point / disk. The admin doing the upgrade can copy the
existing database wherever they need it: tape, another filesystem, NFS
mount, etc.
--
Thomas Swan
---(end of broadcast
Tom Lane wrote:
Dave Smith [EMAIL PROTECTED] writes:
Why not go the other way.
1) Dump the schemas.
2) Initdb with the new schemas in a tmp PGDATA
3) backup the schemas in the current PGDATA
4) move the new schemas from the new db into the current one.
This seems like approximately
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. I like --dump-config. Better to have the verb first.
My only objection to that is that dump suggests you will get some kind
of snapshot of current settings, which is not what this facility does.
Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Are there any objections
to me increasing the block size for FreeBSD installations to 16K for
the upcoming 7.4 release?
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size. That
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm a little uncomfortable with introducing a cross-platform variation
in the standard block size.
Has anyone looked at changing the default block size across the board
and what the performance improvements
On 8/8/2003 5:49 AM, Jason Tishler wrote:
Carlos,
On Fri, Aug 08, 2003 at 09:20:01AM +0200, Carlos Guzman Alvarez wrote:
I want to know if postgresql 7.4 beta 1 can be configured under
Cygwin with SSL support ??
If the answer is positive how can i do it ?? or where can i found
documentation
On 8/20/2003 1:02 PM, Josh Berkus wrote:
Hackers,
I've been searching the archives, but I can't find the thread from last month
where we discussed the problem with Linux memory overcommits in kernel 2.4.x.
Can someone point me to the right thread? I think maybe the subject line was
When a SELECT FOR UPDATE query is executed, are the row level locks on a
table acquired in any specific order such as to enhance deadlock
prevention? ( primary key, oid, etc. )
---(end of broadcast)---
TIP 8: explain analyze is your friend
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
When a SELECT FOR UPDATE query is executed, are the row level locks on a
table acquired in any specific order
Nope, just whatever order the chosen plan happens to visit the tuples
in.
I had remembered several readings
On 7/25/2003 8:10 AM, Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Hypothetically, if I knew the relations that contained the tuples I was
locking, I could conceivably visit them in, let's say, alphabetical
order or oid order or any predictable order, and then select the rows
When a SELECT FOR UPDATE query is executed, are the row level locks on a
table acquired in any specific order such as to enhance deadlock
prevention? ( primary key, oid, etc. )
---(end of broadcast)---
TIP 2: you can get off all lists at once with
Bruce Momjian wrote:
Thomas Swan wrote:
When a SELECT FOR UPDATE query is executed, are the row level locks on a
table acquired in any specific order such as to enhance deadlock
prevention? ( primary key, oid, etc. )
Interesting question, because in a join, you could have multiple
On 7/22/2003 11:18 AM, scott.marlowe wrote:
On Mon, 21 Jul 2003, Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Marcus B?rger wrote:
BM Marcus, would you check if PHP is using RESET ALL when passing
BM persistent connection to new clients? We added that
On 7/21/2003 9:16 AM, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see the problem.
I tend to agree with Peter: if dblink is going to start depending on
stuff outside Postgres, it ought to be become a separate project,
if only to simplify distribution and
Peter Eisentraut wrote:
Thomas Swan writes:
I just am really concerned about the uninstall/clean up phase and how
that can be done in an orderly fashion. Unless the process can start
from a clean state again, then it won't be valid.
The only clean state is if you remove the entire
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Thomas Swan writes:
Have you considered something similar to the Mozilla tinderbox approach
where you have a daemon checkout the cvs, compile, run regression tests,
and report a status or be able to report a status?
Even
Nigel J. Andrews wrote:
On Thu, 26 Jun 2003, Thomas Swan wrote:
Is it possible the sourceforge compile farms could be used for some of
the automated testing? I'm not sure how that system works, but it could
be worth looking into.
Isn't the sourceforge license very scary and along
The Hermit Hacker wrote:
On Thu, 26 Jun 2003, Thomas Swan wrote:
Of course, these are just ideas and I'm not sure how practical it is to
do any of them. I just am really concerned about the uninstall/clean up
phase and how that can be done in an orderly fashion. Unless the
process can start
Larry Rosenman wrote:
--On Saturday, June 21, 2003 11:43:17 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Thomas Swan writes:
Have you considered something similar to the Mozilla tinderbox
approach
where you have a daemon checkout the cvs, compile, run
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It would be nice to have a system which could receive a patch and
compile and verify that it passes the tests before it goes to Bruce's
queue; or compile on multiple platforms to check for portability
problems, for example.
*snip*
Oliver Elphick wrote:
On Thu, 2002-09-12 at 15:54, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
On Thu, 2002-09-12 at 15:31, Tom Lane wrote:
Does anyone see a cleaner answer than re-allowing OPAQUE for PL
handlers?
Neil Conway wrote:
Thomas Swan [EMAIL PROTECTED] writes:
1. create a user with createdb privilege.
2. create a database as that user (allowing that user full reign over
that particular db)
3. drop the createdb from the user.
4. pg_dumpall the databases to a single file
5. either
Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
As an alternative syntax I can suggest
SET name TO value [ ON COMMIT RESET ];
Ugh. Why can't we stick with SET LOCAL?
Tom Lane wrote:
David Ford [EMAIL PROTECTED] writes:
Tom, if you block everyone on cable, dialup, dsl, and adsl, then you're probably blocking a lot of legitimate mail.
David, let me explain this in words of one syllable: I am currently
rejecting upwards of 2000 spam
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
I guess it's a matter of definition: Do you consider SET variablesdatabase state or session metadata? I think some are this and some arethat. I'm not sure how to draw the line, but
Zeugswetter Andreas SB SD wrote:
[EMAIL PROTECTED]">
IMHO, you should copy into a temporary table and the do a select distinct from it into the table that you want.
Which would be way too slow for normal operation :-(We are talking about a "fast as possible" data load from a
Tom Lane wrote:
[EMAIL PROTECTED]">
Vince Vielhaber [EMAIL PROTECTED] writes:
On Thu, 23 Aug 2001, Colin 't Hart wrote:
5. I think Bugzilla's concepts of products, components and versions fitthe way we work.I envisage that 'Postgres', 'Interfaces', 'Languages' might be
Bill Shui wrote:
Hi there,
I remember that in earlier versions of Postgres.
You have to do something (which I cannnot remember) to enable
a user to create plpgsql functions.
which versions of postgres were they?
thanks in advance.
Bill
CREATELANG as
Peter Eisentraut wrote:
Dmitry G. Mastrukov writes:
I've developed new data type for PostgreSQL -unique identifier - 128-bitvalue claims to be unique across Universe. It depends on libuuid frome2fsprogs by Theodore Ts'o.
ISTM that this should be a function, not a data type.
I sit corrected.
*slightly humbled*
Why not do an unsigned int16 to hold your UUID generated numbers. Ultimately,
this would seem to be a more general solution and accomplish your goals at
the sametime. Or, am I completely missing something.
Christopher Kings-Lynne wrote:
don't
Tom Lane wrote:
Awhile ago I said that I wanted to create a new flavor of table-level
lock for concurrent VACUUM to get on a table. RowExclusiveLock is
not the right thing because it is not self-exclusive, whereas we don't
want more than one VACUUM mangling a table at a time. But anything
Michael Meskes wrote:
On Wed, Jun 20, 2001 at 09:13:13AM +0200, Pedro Abelleira Seco wrote:
- Phppgadmin is a web based tool. You need a PHPenabled web server. Most end users/admins don't wantto have to configure a web server, PHP ("what isPHP?") and to have a poor interface (I'm talking
Tom Lane wrote:
[EMAIL PROTECTED]">After fixing the several obvious syntax errors, it works fine for me:regression=# CREATE TABLE messageregression-# (regression(# msgid int4 not null,regression(# msgtext text,regression(# CONSTRAINT cons_001_pk PRIMARY KEY (msgid)regression(# );NOTICE:
Bruce Momjian wrote:
Thomas Swan [EMAIL PROTECTED] writes:
I know that BLOBs are on the TODO list, but I had an idea.
I think you just rediscovered TOAST.
We have TOAST and people want to keep large objects for performance. Ithink we could us an API that allows
I just got bit by the identifier name is too long and will be truncated
limitation in Postgresql.
AFIAA there is a limit of 64 characters for identifiers (names of
tables, sequences, indexes, etc...)
I had just started to get in the habit of using serial data types until
I made to tables
I know that BLOBs are on the TODO list, but I had an idea.
I think the storage of a BLOB outside of the table is an elegant
solution and keeps table sizes down without the bloat of the stored
object. Granted, if you are searching with a regular expression or
using like or ilike clauses,
mlw wrote:
[EMAIL PROTECTED]">Bruce Momjian wrote:
Just put a note in the installation docs that the place where the databaseis initialised to should be on a non-Reiser, non-XFS mount...Sure, we can do that now. What do we do when these are the default filesystems for Linux? We can tell them
At 4/10/2001 02:42 PM, Thomas Lockhart wrote:
Hmm. The problem is as you describe, but the requirements for a solution
are more severe than you (or I) would hope.
We would like to have an extensible mechanism for type promotion and
demotion, but it is not (yet) clear how to implement it. In this
At 3/28/2001 09:52 AM, Joel Burton wrote:
On Wed, 28 Mar 2001, Bruce Momjian wrote:
Actually,
This reminds me of something I have been meaning to ask. All the new
performance features are cool, but what I really need are all the ALTER
TABLE ... functions implemented. In 7.0.x
At 3/20/2001 09:24 PM, Thomas Lockhart wrote:
It's a good start to test with for the purposes for which I think you
want to
test for. (and I'm an English teacher by night -- argh).
:)
Mandrake (as of 7.2) still does a brain-dead mix of "-O3" and
"-ffast-math", which is a risky and
OK, I phoned Tom and we agreed on this wording:
This connection has been terminated by the administrator
Comments?
This connection has been terminated by an administrator
(there may be more than one...) :)
Other than that it's informative enough.
OTOH, I had a small thought on
At 3/14/2001 11:13 AM, Peter Eisentraut wrote:
Thomas Swan writes:
It may seem stupid but I was thinking the reason could be an argument to
the pg_ctl program with a default of (Database Shutdown).
pg_ctl stop --message="System going down for a reboot"
or
pg_ctl stop -m
On reciept of the info signal, the backends collaborate to piece
together a status file. The status file is given a temporay name.
When complete the status file is rename(2)'d over a well known
file.
Reporting to files, particularly well known ones, could lead to race
conditions.
All in all,
At 3/5/2001 04:30 PM, you wrote:
Now, killing the postmaster -9 and not cleaning up the backends has
always been a good way to shoot yourself in the foot, but up to now the
worst thing that was likely to happen to you was isolated corruption in
specific tables. In the brave new world of WAL the
At 1/24/2001 10:19 AM, Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
A patch to gram.y in src/backend/parser
Provides for the SQL99 expected behavior of
select * from foo where fo_num between 1 and 5
yields the same result as
select * from foo where fo_num
= min_value(a, b)) and (fo_num
= max_value(a,b))
This would yield only two comparisons or resolutions and
then a single sequential or index scan to find the correct tuples.
This was done against beta1...
between.patch
--
- Thomas Swan
- Network Administrator
- Graduate Student - Computer Science
I think the list is great, show what can be configured rather than
guessing/digging to find it, where it belongs, in what order (if any), etc.
etc. etc.
The only addition I could think would be to label (default value).
Needless, I like it.. :)
At 1/24/2001 01:03 PM, Bruce Momjian wrote:
I'll take care of fixing what I broke, but does anyone have suggestions
for good names for the two concepts? The best I could come up with
offhand is BEGIN/END_CRIT_SECTION and BEGIN/END_SUPER_CRIT_SECTION,
but I'm not pleased with that... Ideas?
Let CRITICAL be critical. If the other section
At 1/10/2001 09:10 PM, you wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Actually if it were possible to look at the values before expanding. You
could reorder the expression so that it was always the case that B C,
then your cost would only be one comparison plus the sequential scan.
Uh
At 1/9/2001 10:29 PM, Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Shouldn't be much of problem... where would I start to look... :)
Well, the Right Way To Do It would be to invent a new expression node
type that implements both kinds of BETWEEN. Right now, the parser
expands
to
PostgreSQL version 7.1beta2. Check your installation.
I'll see if I can track down what happened a little later
on...
--
- Thomas Swan
- Graduate Student - Computer Science
- The University of Mississippi
-
- People can be categorized into two fundamental
- groups, those that divide people
INSERT INTO ciudad (ciudad) VALUES
(Villa Guillermina)
Use single quotes instead of double quotes.
--
- Thomas Swan
- Graduate Student - Computer Science
- The University of Mississippi
-
- People can be categorized into two fundamental
- groups, those that divide people into two groups
86 matches
Mail list logo
