Any ideas for a temporary work around?
On 12/29/05, Sebastian [EMAIL PROTECTED] wrote:
How many columns in the table?
There are 4 columns in the table
On 12/29/05, Michael Fuhr [EMAIL PROTECTED] wrote:
On Thu, Dec 29, 2005 at 12:12:52PM -0800, Sebastian wrote:
I've waited 10 minutes
On Thu, 2005-12-29 at 11:37 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
My view would be that this thread has been complex because everybody has
expressed a somewhat different requirement, which could be broken down
as:
1. The need for a
On Mon, 2005-12-26 at 13:46 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I suggest the following patch to rename our capability Continuous
Backup.
This doesn't seem like an improvement. Online backup is the standard
terminology AFAIK.
Simon Riggs said:
Following Andrew's concerns, I'd also note that ALTER TABLE requires a
much higher level of privilege to operate than does COPY. That sounds
like it will make things more secure, but all it does is open up the
administrative rights, since full ownership rights must be
Andrew Dunstan [EMAIL PROTECTED] writes:
Simon Riggs said:
Following Andrew's concerns, I'd also note that ALTER TABLE requires a
much higher level of privilege to operate than does COPY. That sounds
like it will make things more secure, but all it does is open up the
administrative rights,
On Thu, Dec 29, 2005 at 10:49:23AM -0500, Tom Lane wrote:
What I'd really like is to deprecate the USING operator syntax in
favor of a USING operatorclassname syntax. Actually, USING opclass
[ASC/DESC] would get the job done, since given an opclass you can
certainly run the sort function
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Dec 29, 2005 at 10:49:23AM -0500, Tom Lane wrote:
What I'd really like is to deprecate the USING operator syntax in
favor of a USING operatorclassname syntax. Actually, USING opclass
[ASC/DESC] would get the job done, since given an
Simon Riggs wrote:
On Thu, 2005-12-29 at 11:37 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
My view would be that this thread has been complex because everybody has
expressed a somewhat different requirement, which could be broken down
as:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Simon Riggs said:
Following Andrew's concerns, I'd also note that ALTER TABLE requires a
much higher level of privilege to operate than does COPY. That sounds
like it will make things more secure, but all it does is open up
Andrew Dunstan wrote:
My concern is more about making plain that this is for special operations,
not normal operations. Or maybe I have misunderstood the purpose.
Rephrase that as full ownership rights must be obtained to load data in
a way that requires dropping any existing indexes
On Fri, Dec 30, 2005 at 03:15:03AM -0500, Sebastian wrote:
Any ideas for a temporary work around?
You could try querying the system catalogs directly instead of using
the information_schema views; look at the view definitions and run
some \d commands under psql -E to see what kinds of queries to
Haven't seen this discussed in a while, but I do recall it being
mentioned sometime before...
The problem:
testdb=# create table mytable (id serial, txt text);
testdb=# grant insert on mytable to user2;
GRANT
testdb=# \connect testdb user2
You are now connected to database testdb as user user2.
Michael Fuhr [EMAIL PROTECTED] writes:
However, EXPLAIN fails in 8.1.1:
test= EXPLAIN SELECT * FROM information_schema.element_types;
ERROR: record type has not been registered
I've applied a patch for this. It's just a bug in EXPLAIN output,
however, and doesn't have anything directly to do
On Fri, 2005-12-30 at 11:49 -0500, Bruce Momjian wrote:
Yes, I know we agreed to the COPY LOCK, but new features now being
requested, so we have to re-evaluate where we are going with COPY LOCK
to get a more consistent solution.
Thank you.
Ah, but people wanted fast INSERT INTO ... SELECT,
It's been several hours since Tom's Repair EXPLAIN failure commit
but anonymous CVS doesn't have it yet. That seems slower than usual;
are there any problems?
--
Michael Fuhr
---(end of broadcast)---
TIP 1: if posting/reading through Usenet,
Simon Riggs wrote:
On Fri, 2005-12-30 at 11:49 -0500, Bruce Momjian wrote:
Yes, I know we agreed to the COPY LOCK, but new features now being
requested, so we have to re-evaluate where we are going with COPY LOCK
to get a more consistent solution.
Thank you.
Good. I think we can be
Michael Fuhr wrote:
It's been several hours since Tom's Repair EXPLAIN failure commit
but anonymous CVS doesn't have it yet. That seems slower than usual;
are there any problems?
cvsup is also unhappy:
[EMAIL PROTECTED] ]# cvsup -g /home/cvsmirror/postgres.cvsup
Cannot connect to
Fixed
On Fri, 30 Dec 2005, Michael Fuhr wrote:
It's been several hours since Tom's Repair EXPLAIN failure commit
but anonymous CVS doesn't have it yet. That seems slower than usual;
are there any problems?
--
Michael Fuhr
---(end of
On Fri, Dec 30, 2005 at 10:18:48AM -0500, Tom Lane wrote:
I really need to study your mail from the other day, but unfortunately
other pressures will probably keep me from getting to it today :-(.
One comment though --- it's not really sane to include ASC/DESC in there
is it? I thought the
As far as EXCLUSIVE or COPY LOCK goes, I think this would be useful
functionality but perhaps there doesn't have to be any proprietary user
interface to it at all. Why not just check if the conditions are already
present to allow the optimization and if so go ahead.
That is, if the current
Greg Stark wrote:
As far as EXCLUSIVE or COPY LOCK goes, I think this would be useful
functionality but perhaps there doesn't have to be any proprietary user
interface to it at all. Why not just check if the conditions are already
present to allow the optimization and if so go ahead.
That
On Fri, 2005-12-30 at 16:14 -0500, Bruce Momjian wrote:
This was discussed on-list by 2 core team members, a committer and
myself, but I see no requirements change here. You even accepted the
invisible COPY optimization in your last post - why unpick that now?
Please forgive my tone, but
Simon Riggs wrote:
On Fri, 2005-12-30 at 16:14 -0500, Bruce Momjian wrote:
This was discussed on-list by 2 core team members, a committer and
myself, but I see no requirements change here. You even accepted the
invisible COPY optimization in your last post - why unpick that now?
On Fri, Dec 30, 2005 at 11:02:20AM -0700, Michael Fuhr wrote:
On Fri, Dec 30, 2005 at 03:15:03AM -0500, Sebastian wrote:
Any ideas for a temporary work around?
You could try querying the system catalogs directly instead of using
the information_schema views;
You could also set
Bruce Momjian pgman@candle.pha.pa.us writes:
BEGIN;
LOCK TABLE foo;
COPY foo from ...
COMMIT;
There could be a COPY LOCK option to obtain a lock, but it would be purely
for
user convenience so they don't have to bother with BEGIN and COMMIt.
The only downside is a check to
Greg Stark wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
BEGIN;
LOCK TABLE foo;
COPY foo from ...
COMMIT;
There could be a COPY LOCK option to obtain a lock, but it would be
purely for
user convenience so they don't have to bother with BEGIN and COMMIt.
Changing enable_nestloop works great -- I'll use it for now. Thanks all
On 12/30/05, Michael Fuhr [EMAIL PROTECTED] wrote:
On Fri, Dec 30, 2005 at 11:02:20AM -0700, Michael Fuhr wrote:
On Fri, Dec 30, 2005 at 03:15:03AM -0500, Sebastian wrote:
Any ideas for a temporary work around?
You
On Fri, 30 Dec 2005, Tom Lane wrote:
I've heard of this in connection with NFS ... is your DB on an NFS
filesystem by any chance?
I have patched IO routines in backend/storage that POSIX says EINTR is
possible except unlink(). Though POSIX says EINTR is not possible, during
many
Martijn van Oosterhout kleptog@svana.org writes:
Yet hashing is also a property of the collation, not the type. The same
string in different locales would hash differently.
I think this is a mistake -- the same mistake that got us into trouble with
Turkish.
Hashing depends on the concept of
Qingqing Zhou [EMAIL PROTECTED] writes:
On Fri, 30 Dec 2005, Tom Lane wrote:
I've heard of this in connection with NFS ... is your DB on an NFS
filesystem by any chance?
I have patched IO routines in backend/storage that POSIX says EINTR is
possible except unlink(). Though POSIX says
I'd like to contribute to localize the application to italian language.
Do you want my help??
I wait your reply.
Michele
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
31 matches
Mail list logo
