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
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 ne
On Mon, 2005-12-26 at 13:46 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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.
>
> B
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 o
"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
>> administrati
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 func
Martijn van Oosterhout 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 opclass
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 d
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 an
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 querie
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
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 ... SELE
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, ple
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 w
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 cv
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 broadcast)--
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 transa
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.
>
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 ton
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 n
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 enable_
Bruce Momjian 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 see
Greg Stark wrote:
> Bruce Momjian 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?
>
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 regressi
Martijn van Oosterhout 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 equality which i
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
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
