Hmm. This error is not coming from "a line of the copy", it is occurring
because the COPY command itself fails, and so the server never tells
psql to shift into COPY mode. I'm not sure that a reasonable fix for
this is possible. As a counterexample, if you misspelled COPY as COPZ,
would you expe
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Presently you get a million lines of '\N command not recognised' and
> various other random things because if a line of the copy fails due to
> say a FK constraint, or even if the COPY is run in an aborted
> transaction, it tries to execute a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We've done quite well with the current setup, so I don't see a need to
> tinker with it. I've always found the Reply-to-enabled lists I'm on to
> be a more lossy medium.
The basic issue is that the current setup encourages
reply-to-author-and-list,
Presently you get a million lines of '\N command not recognised' and
various other random things because if a line of the copy fails due to
say a FK constraint, or even if the COPY is run in an aborted
transaction, it tries to execute all the stdin data as actual
statements.
I'd like to see a t
Bruce Momjian said:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> > OK, what solutions do we have for this? Not being able to load
>> > dumped data is a serious bug.
>>
>> Which we do not have, because pg_dump doesn't use CSV. I do not think
>> this is a must-fix, especially n
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I would like to beg for some sort of fix to psql's handling of COPY data
> if the COPY fails.
> Presently you get a million lines of '\N command not recognised' and
> various other random things because if a line of the copy fails due to
> s
Doug McNaught said:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>
>> No, the poster will still be included as part of the headers ... what
>> happens, at least under Pine, is that I am prompted whther I want to
>> honor the reply-to, if I hit 'y', then the other headers *are* strip'd
>> and th
Marc G. Fournier wrote:
> What is the general opinion of this? I'd like to implement it, but
> not so much so that I'm going to beat my head against a brick wall on
> it ...
Please, please, please, please don't. The choice of the reply path lies
with the author or the replier, not with an inter
Christopher Kings-Lynne wrote:
Also, sometimes when you copy and paste SQL into a psql window, it
executes help on commands for each line, although it doesn't affect the
paste. That is also really annoying. I'll add to this email when it
happens to me again, cos I tried a few pastes and couldn
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, what solutions do we have for this? Not being able to load dumped
> > data is a serious bug.
>
> Which we do not have, because pg_dump doesn't use CSV. I do not think
> this is a must-fix, especially not if the proposed fix intr
I would like to beg for some sort of fix to psql's handling of COPY data
if the COPY fails.
Presently you get a million lines of '\N command not recognised' and
various other random things because if a line of the copy fails due to
say a FK constraint, or even if the COPY is run in an aborted
On Wed, 2004-11-24 at 20:25 -0500, Bruce Momjian wrote:
> FreeBSD had a problem with double-dash args but I thought that related
> to getopt, and I can't remember how that fits in. Maybe we defined '-'
> in getopt and said it took an argument and tested for '-help' and
> '-verbose', but now we jus
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, what solutions do we have for this? Not being able to load dumped
> data is a serious bug.
Which we do not have, because pg_dump doesn't use CSV. I do not think
this is a must-fix, especially not if the proposed fix introduces
inconsistencies elsew
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> No, the poster will still be included as part of the headers ... what
> happens, at least under Pine, is that I am prompted whther I want to
> honor the reply-to, if I hit 'y', then the other headers *are* strip'd
> and the mail is set right back to
Marc G. Fournier wrote:
> On Sun, 28 Nov 2004, Bruce Momjian wrote:
>
> >
> > Are you saying this is going to make it impossible for me to reply just
> > to the poster, or is this an option that is set by the user via majordomo?
>
> No, the poster will still be included as part of the headers ...
On Sun, 28 Nov 2004, Bruce Momjian wrote:
Are you saying this is going to make it impossible for me to reply just
to the poster, or is this an option that is set by the user via majordomo?
No, the poster will still be included as part of the headers ... what
happens, at least under Pine, is that I
OK, what solutions do we have for this? Not being able to load dumped
data is a serious bug. I have added this to the open items list:
* fix COPY CSV with \r,\n in data
My feeling is that if we are in a quoted string we just process whatever
characters we find, even passing through an
Are you saying this is going to make it impossible for me to reply just
to the poster, or is this an option that is set by the user via majordomo?
---
Jim Seymour wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
> >
>
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
>
>
> What is the general opinion of this? I'd like to implement it, but not so
> much so that I'm going to beat my head against a brick wall on it ...
The procmail rules I set up for each mailing list to which I subscribe
sets Reply-To to the mail
Matthew T. O'Connor looked at this fairly closely leading up to 8.0
feature freeze. There was a long discussion earlier this year with respect
to libpq vs. using backend functions directly to vacuum multiple
databases.
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00931.php
This should
I have added an auto-vacuum TODO item:
* Auto-vacuum
o Move into the backend code
o Scan the buffer cache to find free space or use background writer
o Use free-space map information to guide refilling
-
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> What is the quality of the large object solution today. Does it have
> known flaws that nobody cares about since it's discontinued or is it
> considered a maintained and worthy part of the overall solution?
More the former than the latter, I think, a
Is this a TODO?
---
Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I suppose it might be useful to have some kind of "suspended animation"
> > behavior where you could bring up a backend and look at the d
Hi All,
I am doing serious thinking about the implementation of Auto Vacuum as part of
the backend, Not using libpq, but classing internal functions directly.
It appears to me that calling internal functions directly is a better
implementation than using the external library to do the job.
I kn
I assume this is not something for our PostgreSQL CVS, even the later
SRF implementation.
---
John Hansen wrote:
> Attached, array -> rows iterator.
>
> select * from unnest(array[1,2,3,4,5]);
>
> Unnest
> ---
Should I add a TODO to warn if FSM values are too small? Is that doable?
---
Marc G. Fournier wrote:
>
> Moved to -hackers where this belongs :)
>
> On Fri, 5 Nov 2004, Justin Clift wrote:
>
> > Tom Lane wrote:
> >
> >>
David Garamond <[EMAIL PROTECTED]> writes:
> I find it nonintuitive and hard to remember. Perhaps something like this
> is better (I know, it's probably too late):
> ALTER [ COLUMN ] column SET STORAGE { INLINE | EXTERNAL }
> ALTER [ COLUMN ] column SET COMPRESSION { YES | NO }
The semantics
Joe Conway wrote:
Not if the column is storage type EXTERNAL. See a past discussion here:
http://archives.postgresql.org/pgsql-general/2003-07/msg01447.php
what is the reasoning behind this syntax?
ALTER TABLE [ ONLY ] table [ * ]
ALTER [ COLUMN ] column SET STORAGE
{ PLAIN | EXTERNAL | EXTENDED
On Sun, 2004-11-28 at 22:35, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Given we expect an underestimate, can we put in a correction factor
> > should the estimate get really low...sounds like we could end up
> > choosing nested joins more often when we should have chosen merge j
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> What is the general opinion of this? I'd like to implement it, but not so
> much so that I'm going to beat my head against a brick wall on it ...
I think we've discussed this in the past, and the consensus has always
been that more people like it
On Sat, 2004-11-27 at 23:11 -0500, Bruce Momjian wrote:
> Is there a TODO here? Or a few?
Sure: you could add a TODO item like "Improve psql schema behavior", and
assign it to me. I'll send in a patch that implements the behavior I
proposed for 8.1
-Neil
---(end of bro
What is the general opinion of this? I'd like to implement it, but not so
much so that I'm going to beat my head against a brick wall on it ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7
Troels Arvin <[EMAIL PROTECTED]> writes:
> On Sun, 28 Nov 2004 16:52:47 -0500, Tom Lane wrote:
>> You need to be able
>> to scan the index and identify rows matching a query without making lots
>> of probes into the table.
> But is it cheaper, IO-wise to "jump" around in an index than to go back
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> Given we expect an underestimate, can we put in a correction factor
> should the estimate get really low...sounds like we could end up
> choosing nested joins more often when we should have chosen merge joins.
One possibility: vacuum already knows how many
Joe Conway wrote:
Thomas Hallgren wrote:
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
Hmm, ok. But there's no way to stream them in and out from disk. From
what I can see, you have to bring all of it into memory. Not so ideal
perhaps if you want to provide st
Oliver Jowett <[EMAIL PROTECTED]> writes:
>> Perhaps PerformCursorOpen should copy the query tree before planning, or
>> plan in a different memory context?
> Patch attached. It moves query planning inside the new portal's memory
> context. With this applied I can run Barry's testcase without er
On Sun, 2004-11-28 at 18:52, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On the topic of accuracy of the estimate: Updates cause additional data
> > to be written to the table, so tables get bigger until vacuumed. Tables
> > with many Inserts are also regularly trimmed with Delete
Simon Riggs wrote:
>
> Could I suggest that we re-work the TODO list slightly, with regard to
> mentioning the ANSI SQL standard?
>
> As of last count, we have 14 items listed which would take PostgreSQL
> into full SQL:2003 Core conformance. Troels Arvin has recently listed
> some of these as "l
On Sun, 28 Nov 2004 16:52:47 -0500, Tom Lane wrote:
> CTID (block # + line #) is the only valid pointer from an index to a
> table.
Thanks.
> I think
> though that you'd be making a serious mistake by not duplicating the
> suffixes into the index (rather than expecting to retrieve them from the
Could I suggest that we re-work the TODO list slightly, with regard to
mentioning the ANSI SQL standard?
As of last count, we have 14 items listed which would take PostgreSQL
into full SQL:2003 Core conformance. Troels Arvin has recently listed
some of these as "low hanging fruit" in the recent t
Troels Arvin <[EMAIL PROTECTED]> writes:
> What kind of (logical) block identifier should I point to in my index?
CTID (block # + line #) is the only valid pointer from an index to a
table. It doesn't change over the life of an index entry. I think
though that you'd be making a serious mistake b
On Fri, 19 Nov 2004 10:35:20 -0500, Tom Lane wrote:
>> 2. Does someone know of interesting documentation (perhaps
>>in the form of interesting code comments) which I should
>>read, as a basis for creating a non-standard index type
>>in PostgreSQL?
>
> There's not a whole lot :-( and y
Hello Christopher, Hello Tom,
thank you for your answers.
You are using a pre-release version of a database server, and
phpPgAdmin's behaviour has had to change _several_ times to track it.
Don't expect a pre-release to work in any way.
I know that PostgreSQL 8.0 isn't ready for use in productio
[EMAIL PROTECTED] (Jim Seymour) writes:
> I'm kind of wondering if anybody on the dev team noticed this and
> what, if anything, they planned to do with it?
Can we make it "#ifdef SOLARIS7" somehow? I'm uneager to put a
performance penalty on every platform because of an admittedly
broken signal
Simon Riggs <[EMAIL PROTECTED]> writes:
> On the topic of accuracy of the estimate: Updates cause additional data
> to be written to the table, so tables get bigger until vacuumed. Tables
> with many Inserts are also regularly trimmed with Deletes. With a
> relatively static workload and a regular
Thomas Hallgren wrote:
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
Hmm, ok. But there's no way to stream them in and out from disk. From
what I can see, you have to bring all of it into memory. Not so ideal
perhaps if you want to provide streaming media for
-Original Message-
From: [EMAIL PROTECTED] on behalf of Christopher Kings-Lynne
Sent: Sun 11/28/2004 2:57 PM
To: Roland Volkmann
Cc: PostgreSQL Developers
Subject: Re: [HACKERS] Error: column "nsptablespace" does not exist
> No other applications will be broken because no other applica
On Sat, 2004-11-27 at 00:54, Tom Lane wrote:
> "Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
> >> rel->pages = RelationGetNumberOfBlocks(relation);
>
> > Is RelationGetNumberOfBlocks cheap enough that you can easily use it for the
> > optimizer ?
>
> It's basically going to cost one ex
The "inv_api" large objects are deprecated. CLOBs and BLOBs should be based
on text and bytea, respectively.
Until bytea is actually useful with large scale binaries I would
say that large objects are far from deprecated. You can't reasonably
store large binary date in bytea.
Large objects ar
--On Sonntag, November 28, 2004 14:55:29 +0100 Thomas Hallgren
<[EMAIL PROTECTED]> wrote:
From what I can see, the current JDBC driver uses the lo_ client
api's and they seem to map to the inv_ server api's.
Huh, does that mean the libpq's lo_*() API is deprecated, too? That would
be bad news..
with the new Beta5 you will receive an error ""column "nsptablespace"
does not exist"" on phpPgAdmin and EMS PostgreSQL-Manager. Perhaps there
will be some more applications around which are broken now.
What is the future in this area? Back to schema of Beta4, or must all
the utilities be porte
Hi,
I'm kind of wondering if anybody on the dev team noticed this and
what, if anything, they planned to do with it?
Jim
[EMAIL PROTECTED] (Jim Seymour) wrote:
>
>
> Hi,
>
> Environment:
>
> SunOS 5.7 Generic_106541-29 sun4u sparc SUNW,UltraSPARC-IIi-Engine
> Postgresql-7.4.6
>
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > However, I am wondering if we should create a character lookup during
> > initdb that has the characters ordered so we can do:
>
> That won't work. Real-life collations are too complicated.
OK.
> > Also, we mention you should use the "C" locale
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
Hmm, ok. But there's no way to stream them in and out from disk. From
what I can see, you have to bring all of it into memory. Not so ideal
perhaps if you want to provide streaming media for thousands of users.
Yo
Am Sonntag, 28. November 2004 12:33 schrieb Thomas Hallgren:
> Hmm, ok. But there's no way to stream them in and out from disk. From
> what I can see, you have to bring all of it into memory. Not so ideal
> perhaps if you want to provide streaming media for thousands of users.
You can use the subs
> Am Sonntag, 28. November 2004 10:22 schrieb Thomas Hallgren:
> > I'm in the phase of implementing CLOB's and BLOB's in PL/Java. I found
> > the inv_api.c and will use that as the base for my implementation.
>
> The "inv_api" large objects are deprecated. CLOBs and BLOBs should be based
> on te
Peter Eisentraut wrote:
Am Sonntag, 28. November 2004 10:22 schrieb Thomas Hallgren:
I'm in the phase of implementing CLOB's and BLOB's in PL/Java. I found
the inv_api.c and will use that as the base for my implementation.
The "inv_api" large objects are deprecated. CLOBs and BLOBs should
Am Sonntag, 28. November 2004 10:22 schrieb Thomas Hallgren:
> I'm in the phase of implementing CLOB's and BLOB's in PL/Java. I found
> the inv_api.c and will use that as the base for my implementation.
The "inv_api" large objects are deprecated. CLOBs and BLOBs should be based
on text and bytea
Hi,
I'm in the phase of implementing CLOB's and BLOB's in PL/Java. I found
the inv_api.c and will use that as the base for my implementation. I
lack two calls:
int inv_length(LargeObjectDesc* lo);
void inv_truncate(LargeObjectDesc* lo, int position);
Searching the archives I found some questions
Bruce Momjian wrote:
> However, I am wondering if we should create a character lookup during
> initdb that has the characters ordered so we can do:
That won't work. Real-life collations are too complicated.
> Also, we mention you should use the "C" locale to use normal indexes
> for LIKE but isn
Bruce Momjian wrote:
> I saw Peter's commit to allow NLS lookups from libpgport functions.
> Here is the change to pg_ctl/nls.mk:
>
> < GETTEXT_FILES := pg_ctl.c
>
> > GETTEXT_FILES := pg_ctl.c ../../port/exec.c
>
> Peter, do you have to know the C file used by pg_ctl to make these
> adjustments?
> I know we can't currently use an index with non-C locales and LIKE
> except when we create a sepcial type of index for LIKE indexing
> (text_pattern_ops).
>
> However, I am wondering if we should create a character lookup during
> initdb that has the characters ordered so we can do:
>
> c
62 matches
Mail list logo
