On Fri, 26 Sep 2003 04:51 pm, Christopher Kings-Lynne wrote:
> Yes I do, but sometimes as different users you don't know what the path
> is. I guess I can just go --version.
Perhaps add
alias initdb='initdb --version; initdb'
to /etc/profile so that all accounts get an alias?
Regards, Philip Y
On Fri, 26 Sep 2003, Christopher Kings-Lynne wrote:
> > If you install many different versions in parallel, don't you give your
> > installation paths some meaning that contain the version number? In any
> > case, you can run initdb --version first if you're not sure about what is
> > where.
>
>
I note there is no pretty printing option for pg_get_triggerdef...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
> "When the address-of operator is applied to a thread-local variable, it
> is evaluated at run-time and returns the address of the current thread's
> instance of that variable. An address so obtained may be used by any
> thread. When a thread terminates, any pointers to thread-local variables
Christopher Kings-Lynne wrote:
I note there is no pretty printing option for pg_get_triggerdef...
Right.
There's no expression tree displayed, which would make the pretty print
option necessary.
As long as we don't have reengineering functions for *all* objects, it
doesn't make sense to impleme
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> AFAIK, no commercial database does predicate locking either,
True ..
Tom> so we all fall short of true serializability. The usual
Tom> solution if you need the sort of behavior you're talking
Tom> about is to take a non-s
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> All TLS variables *must* be static (or implicitly static
>> through extern, i.e. no 'auto' variables)
>I assume you mean static as in not-auto, rather than static as in
>not-global. Otherwise we have a problem here.
Yes, you are cor
Tom Lane wrote:
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
One thing that can be done is to arrange all globals/statics in a
structure and make that structure thread local.
That's about as far from "non-invasive" as I can imagine :-(
I know.
I have following half baked solution. Obviously
On Friday 26 September 2003 02:29, Shridhar Daithankar wrote:
> Well, I am sure there are data corruption bugs fixed between 6.2 and
> current CVS head which would count as large impact in terms of numbers and
> severity.
Indeed there are.
> Its not like oracle upgrade where you have to move the
No, I got this job 2 months ago, I don`t know who managed it before, and I
don`t know why didn`t he upgrade. Until this week I didn`t have the chance
to upgrade.
But it runs now on 7.3.4.
On Thu, 25 Sep 2003, Richard Huxton wrote:
> On Thursday 25 September 2003 07:36, Hornyak Laszlo wrote:
> >
>> Okay, I'll work out some extension of the APIs to let us propagate the
>> snapshot request down through SPI and into the Executor, rather than
>> using a global variable for it. (Unless someone has a better idea...)
Just when you thought it was safe to go back in the water ...
Chris Kratz sen
On Fri, 26 Sep 2003, Christopher Kings-Lynne wrote:
> >>Is there any chance we could have initdb show the version of postgresql
> >>it is running as when initdb is run?
> >
> >
> > If you install many different versions in parallel, don't you give your
> > installation paths some meaning that co
On Friday 26 September 2003 19:50, Tom Lane wrote:
> Anyway, on to Chris' example. Load the attached script into a database
> that has plpgsql already created, and then do
> DELETE FROM Activity WHERE ActivityID = 16739;
> You'll get
> ERROR: attempted to mark4update invisible tuple
>
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> Moral of the story, if it's in your path first then it's the default and you
> should therefore be happy with the results or be prepared to live with them,
> otherwise make sure what you're running.
I would think that having initdb print its version
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Surely the addresses can be assumed constant within a thread.
>> Otherwise we have a problem here too.
> Quoting from the MSDN:
> The address of a thread local object is not considered constant, and any
> expression involving such a
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> We really don't need threads to replace existing functionality. That
> would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack of fork(), which means there's
no way for separate-sub
Lamar Owen <[EMAIL PROTECTED]> writes:
> This isn't necessarily true. That old of a version of PostgreSQL is probably
> running on a quite out-of-date OS -- for instance, if the OS was Red Hat
> Linux, then the point at which 6.2.1 was shipped was RHL 5.0. Can you even
> compile PostgreSQL 7.3.
On Friday 26 September 2003 20:19, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > We really don't need threads to replace existing functionality. That
> > would be dog work.
>
> No, that's not the point at all. The problem we are facing at the
> moment with the Windows port
Tim McAuley <[EMAIL PROTECTED]> writes:
> Another question now. I am unable to compile Postgresql 7.4 beta 3 under
> cygwin (Windows 2K, using cgyipc 2).
> I am getting the error:
> "
> creating information schema... ERROR: end-of-copy marker does not match
> previous newline style
> CONTEXT:
On Fri, 2003-09-26 at 11:01, Tom Lane wrote:
> so it appears that cygwin's "echo" generates a different newline style
> than what got put into sql_features.txt. A possible way to fix this is
> to put the "\." line into sql_features.txt, but maybe there's a cleaner
> answer. Peter, any thoughts?
Tom Lane wrote:
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
Moral of the story, if it's in your path first then it's the default and you
should therefore be happy with the results or be prepared to live with them,
otherwise make sure what you're running.
I would think that having initdb
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> If the trigger function is precompiled, the error would not be reproducible
> and it will work correctly, right?
Only because the trigger in the example doesn't issue any queries of its
own. If it did, it would cause CommandCounterIncrement(s) an
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Surely the addresses can be assumed constant within a thread.
Otherwise we have a problem here too.
Quoting from the MSDN:
The address of a thread local object is not considered constant, and any
express
On Fri, Sep 26, 2003 at 11:01:34AM -0400, Tom Lane wrote:
> > I am getting the error:
> > "
> > creating information schema... ERROR: end-of-copy marker does not match
> > previous newline style
> > CONTEXT: COPY FROM, line 361
> > "
>
> That's interesting. COPY is complaining because the \. t
On Friday 26 September 2003 10:52, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > This isn't necessarily true. That old of a version of PostgreSQL is
> > probably running on a quite out-of-date OS -- for instance, if the OS was
> > Red Hat Linux, then the point at which 6.2.1 was shi
Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > We really don't need threads to replace existing functionality. That
> > would be dog work.
>
> No, that's not the point at all. The problem we are facing at the
> moment with the Windows port is lack of fork(), which means the
This item has been added to the 7.4 open items list:
ftp://momjian.postgresql.org/pub/postgresql/open_items
---
Rod Taylor wrote:
-- Start of PGP signed section.
> Below is output from 7.3 pg_dump that is being load
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One solution is for me to continue with this in the Win32 CVS version
> until I have fork/exec() working on Unix, then test on Win32. I think
> that could be done in a few weeks, if not less.
> Another solution, already mentioned, is to use threads and
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One solution is for me to continue with this in the Win32 CVS version
> > until I have fork/exec() working on Unix, then test on Win32. I think
> > that could be done in a few weeks, if not less.
>
> > Another solution, already menti
On Fri, 26 Sep 2003, Tom Lane wrote:
> >> Okay, I'll work out some extension of the APIs to let us propagate the
> >> snapshot request down through SPI and into the Executor, rather than
> >> using a global variable for it. (Unless someone has a better idea...)
>
> Just when you thought it was sa
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I think theoretically in serializable the cases where the difference
> between the snapshot from this statement and the standard snapshot for the
> transaction are noticable we probably have a serialization failure
Hmm, that is a good point. It would be
Zeugswetter Andreas SB SD wrote:
>
> > > From our previous discussion of 2-phase commit, there was concern that
> > > the failure modes of 2-phase commit were not solvable. However, I think
> > > multi-master replication is going to have similar non-solvable failure
> > > modes, yet people still
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Could we allow slaves to check if the backend is still alive, perhaps by
> asking the postmaster, similar to what we do with the cancel signal ---
> that way, the slave would never time out and always wait if the master
> was alive.
You're not considerin
Alvaro Herrera writes:
> Regarding your message cleanup, I wonder about:
>
> #: rewrite/rewriteDefine.c:274
> msgid "rules on SELECT rule must have action INSTEAD SELECT"
>
> Is this really the intended wording?
>
> #: utils/misc/guc.c:1318
> msgid "log statement generating error at or above this
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Could we allow slaves to check if the backend is still alive, perhaps by
> > asking the postmaster, similar to what we do with the cancel signal ---
> > that way, the slave would never time out and always wait if the master
> > was ali
On Fri, 26 Sep 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Could we allow slaves to check if the backend is still alive, perhaps by
> > asking the postmaster, similar to what we do with the cancel signal ---
> > that way, the slave would never time out and always wait i
On Fri, 26 Sep 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Could we allow slaves to check if the backend is still alive, perhaps by
> > asking the postmaster, similar to what we do with the cancel signal ---
> > that way, the slave would never time out and always wait i
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
> if we are talking two computers sitting next to each other on a switch,
> you'd expect those to be low ... but if you were talking about two
> seperate geographical locations (and yes, I realize you are adding lag to
> the mix
Patrick Welche wrote:
> On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
> ...
> > if we are talking two computers sitting next to each other on a switch,
> > you'd expect those to be low ... but if you were talking about two
> > seperate geographical locations (and yes, I realize
Tom Lane writes:
> so it appears that cygwin's "echo" generates a different newline style
> than what got put into sql_features.txt. A possible way to fix this is
> to put the "\." line into sql_features.txt, but maybe there's a cleaner
> answer. Peter, any thoughts?
There's no clean answer to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You're not considering the possibility of a transient communication
>> failure.
> Can't the master re-send the request after a timeout?
Not "it can", but "it has to". The master *must* keep hold of that
request forever (or until the
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> so it appears that cygwin's "echo" generates a different newline style
>> than what got put into sql_features.txt. A possible way to fix this is
>> to put the "\." line into sql_features.txt, but maybe there's a cleaner
>> answer.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> You're not considering the possibility of a transient communication
> >> failure.
>
> > Can't the master re-send the request after a timeout?
>
> Not "it can", but "it has to". The master *must* keep hold of tha
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 26, 2003 9:27 AM
> To: Bruce Momjian
> Cc: Shridhar Daithankar; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Threads vs Processes
>
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> so it appears that cygwin's "echo" generates a different newline style
> >> than what got put into sql_features.txt. A possible way to fix this is
> >> to put the "\." line into sql_features.txt, but maybe the
Bruce Momjian wrote:
I posted on that a few minutes ago. Yea, we can drop it, but we risk
eating carraige returns as data values. I am not sure how consistently
we output literal carriage returns in old dumps, nor how many apps
produce on literal carriage returns in COPY. If we conditionally eat
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Perhaps we can throw a warning rather than an error, and adjust initdb
> to be consistent.
I like the idea of reducing the newline consistency check to a warning.
There is one thing we'd have to watch for though (it's already an issue
but would become a
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >I posted on that a few minutes ago. Yea, we can drop it, but we risk
> >eating carraige returns as data values. I am not sure how consistently
> >we output literal carriage returns in old dumps, nor how many apps
> >produce on literal carriage re
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Perhaps we can throw a warning rather than an error, and adjust initdb
> > to be consistent.
>
> I like the idea of reducing the newline consistency check to a warning.
> There is one thing we'd have to watch for though (it's already
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
On Fri, 26 Sep 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> You're not considering the possibility of a transient communication
> >> failure.
>
> > Can't the master re-send the request after a timeout?
>
> Not "it can", but "it has to". The master *
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... we could add code to throw the WARNING
> only once per COPY command --- that would probably make sense.
Seems like a bit of a kluge, but perhaps the best compromise. It would
be quite likely that you'd get the same warning on many lines of a COPY,
a
Tom Lane writes:
> Yeah, I was wondering whether you wouldn't propose dropping the newline
> consistency check. I'm not very comfortable with that, but maybe we
> should. Bruce?
I don't mind if we keep it on pure-POSIX platforms. But one of the nicer
developments on Windows in recent(?) times
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... we could add code to throw the WARNING
> > only once per COPY command --- that would probably make sense.
>
> Seems like a bit of a kluge, but perhaps the best compromise. It would
> be quite likely that you'd get the same warnin
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Tom Lane writes:
> > >> so it appears that cygwin's "echo" generates a different newline style
> > >> than what got put into sql_features.txt. A possible way to fix this is
> > >> to
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
> to a 7.4beta3 database is producing some errors like this:
> ERROR: literal newline found in data
> HINT: Use "\n" to represent newline.
> CONTEXT: COPY FROM, line 59
> E
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Yeah, I was wondering whether you wouldn't propose dropping the newline
>> consistency check. I'm not very comfortable with that, but maybe we
>> should. Bruce?
> I don't mind if we keep it on pure-POSIX platforms. But one of th
Tom Lane wrote:
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> > CONTEXT: COPY FROM, line 41
>
> Really? 7.2 should dump data \r or \n as the backslash versions ...
> and does in my tests. Can you make a reproducible test case?
>
>
>
> >
Tom Lane wrote:
I don't mind if we keep it on pure-POSIX platforms. But one of the nicer
developments on Windows in recent(?) times is that you can actually use
any kind of line separator and most programs still work correctly (with
the notable exception of Notepad).
Not sure if we should ma
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Patrick Welche wrote:
>> On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
>> ...
>> > if we are talking two computers sitting next to each other on a switch,
>> > you'd expect those to be low ... but if you were talking about two
>> > se
On Fri, 26 Sep 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I think theoretically in serializable the cases where the difference
> > between the snapshot from this statement and the standard snapshot for the
> > transaction are noticable we probably have a serialization fa
On Fri, 26 Sep 2003, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
> > to a 7.4beta3 database is producing some errors like this:
>
> > ERROR: literal newline found in data
> > HINT: Use "\n" to repr
scott.marlowe wrote:
> The attached file produces this problem. Note it's a blank trailing field
> that looks to be causing it. The error for this .sql file is:
>
> ERROR: literal carriage return found in data
> HINT: Use "\r" to represent carriage return.
> CONTEXT: COPY FROM, line 2
>
> N
On Fri, Sep 26, 2003 at 01:34:28PM -0400, Tom Lane wrote:
>
> Example:
>
> Master Slave
> -- -
> commit ready-->
> <--OK
> commit done->XX
> maybe he didn't. Both sides are forced to keep information about the
> open trans
Bruce Momjian wrote:
> scott.marlowe wrote:
> > The attached file produces this problem. Note it's a blank trailing field
> > that looks to be causing it. The error for this .sql file is:
> >
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> >
On Fri, Sep 26, 2003 at 02:05:36PM -0400, Tom Lane wrote:
> a valid slave anymore. You can make this work, but the resource costs
> are steep. For instance, in Postgres, you don't get to truncate the WAL
But people who want 2PC are more than willing to pay all that cost.
A
--
Andrew Sull
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > The attached file produces this problem. Note it's a blank trailing field
> > that looks to be causing it. The error for this .sql file is:
> >
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represen
scott.marlowe wrote:
> > OK, 'vi' shows it as:
> >
> > COPY people2 (id, persons) FROM stdin;
> > 59 Chance Terry--S
> > 60 ^M
> > \.
> >
> > which is _exactly the case the error was supposed to catch. Now, the
> > big question is where did this dump come from? Pg
On Fri, Sep 26, 2003 at 03:05:58PM -0400, Tom Lane wrote:
> Not sure if we should make the behavior Windows-specific though. And
> didn't Michael report seeing the same initdb failure on Debian? That
> confuses me a bit --- why would there be a newline discrepancy on Debian?
I take it there are
On Fri, 26 Sep 2003, Christopher Browne wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Patrick Welche wrote:
> >> On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
> >> ...
> >> > if we are talking two computers sitting next to each other on a switch,
> >> > you'd expect
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > > OK, 'vi' shows it as:
> > >
> > > COPY people2 (id, persons) FROM stdin;
> > > 59 Chance Terry--S
> > > 60 ^M
> > > \.
> > >
> > > which is _exactly the case the error was supposed to catch. Now, the
> >
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > > OK, 'vi' shows it as:
> > >
> > > COPY people2 (id, persons) FROM stdin;
> > > 59 Chance Terry--S
> > > 60 ^M
> > > \.
> > >
> > > which is _exactly the case the error was supposed to catch. Now, the
> >
scott.marlowe writes:
> table name too, like Bruce said. The bothersome bit is that in pg_dump,
> it says the line, relative to just this part of the copy command, so you
> don't even know which table is giving the error.
I don't see the problem. Can't you identify the failing command by the
li
Bruce Momjian writes:
> The argument that you want a warning because you might have mixed
> newlines in the file seems less likely than this case where they are
> using a literal carriage return as a data value at the end of the line.
I don't agree with that assessment. Who actually has CRs in t
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The argument that you want a warning because you might have mixed
> > newlines in the file seems less likely than this case where they are
> > using a literal carriage return as a data value at the end of the line.
>
> I
scott.marlowe writes:
> but I get basically the same thing if I dump it to a .sql file and do:
>
> psql dbname
--On Friday, September 26, 2003 14:36:08 -0600 "scott.marlowe"
<[EMAIL PROTECTED]> wrote:
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
Bruce Momjian writes:
> The argument that you want a warning because you might have mixed
> newlines in the file seems less likely than this case where they a
On Fri, 2003-09-26 at 13:58, Bruce Momjian wrote:
> Patrick Welche wrote:
> > On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
> > ...
> > > if we are talking two computers sitting next to each other on a switch,
> > > you'd expect those to be low ... but if you were talking about
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> scott.marlowe writes:
>> but I get basically the same thing if I dump it to a .sql file and do:
>> psql dbname Use psql -f dbname.sql instead.
This doesn't seem like a good argument not to add more information to
the CONTEXT line for COPY errors. Su
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > but I get basically the same thing if I dump it to a .sql file and do:
> >
> > psql dbname
> Use psql -f dbname.sql instead.
and the output is:
psql:webport.sql:803: ERROR: function "odbc_user" already exists with
sa
On Fri, 26 Sep 2003, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > scott.marlowe writes:
> >> but I get basically the same thing if I dump it to a .sql file and do:
> >> psql dbname
> > Use psql -f dbname.sql instead.
>
> This doesn't seem like a good argument not to add mo
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > table name too, like Bruce said. The bothersome bit is that in pg_dump,
> > it says the line, relative to just this part of the copy command, so you
> > don't even know which table is giving the error.
>
> I don't see th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> The argument that you want a warning because you might have mixed
>> newlines in the file seems less likely than this case where they are
>> using a literal carriage return as a data value at the end of the line.
> I don't agr
> The first problem is the restart/rejoin problem. When a 2PC member
> goes away, it is supposed to come back with all its former locks and
> everything in place, so that it can know what to do. This is also
> extremely tricky, but I think the answer is sort of easy. A member
> which re-joins wi
scott.marlowe writes:
> psql:webport.sql:803: ERROR: function "odbc_user" already exists with
> same argument types
> REVOKE
> REVOKE
> GRANT
> You are now connected as new user "ayousuff".
> psql:webport.sql:869: ERROR: literal newline found in data
> HINT: Use "\n" to represent newline.
> CON
I said:
> The question isn't so much "who has CRs in their data" as "who is trying
> to import data files in which CRs aren't correctly represented as \r" ?
> Not anyone upgrading from a recent PG release ... though 7.1 or before
> would have an issue.
Actually, checking the CVS logs shows that 7.
Tom Lane writes:
> This doesn't seem like a good argument not to add more information to
> the CONTEXT line for COPY errors. Sure, in theory the existing info
> should be sufficient, but what if the information is not coming in
> through psql? (For instance, maybe the COPY data is being generate
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The argument that you want a warning because you might have mixed
> > newlines in the file seems less likely than this case where they are
> > using a literal carriage return as a data value at the end of the line.
>
> I don't agree with that
Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > table name too, like Bruce said. The bothersome bit is that in pg_dump,
> > it says the line, relative to just this part of the copy command, so you
> > don't even know which table is giving the error.
>
> I don't see the problem. Can't you
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Minimalism isn't really a virtue in error reports anyway.
>> I'm thinking maybe:
>> CONTEXT: COPY tablename, line 41: "data ..."
>> would serve the purpose nicely.
> The only thing that would really help in the general case is the number of
> the ch
Marc G. Fournier wrote:
> On Fri, 26 Sep 2003, Tom Lane wrote:
>
>>Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>>>Tom Lane wrote:
>>>
You're not considering the possibility of a transient communication
failure.
>>
>>>Can't the master re-send the request after a timeout?
>>
>>Not "it can"
On Fri, 26 Sep 2003, Christopher Browne wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Patrick Welche wrote:
> >> On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
> >> ...
> >> > if we are talking two computers sitting next to each other on a switch,
> >> > you'd expect th
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Peter, do you remember that?
> BE_DLLLIBS; see Makefile.cygwin for example. (AIX has a similar
> requirement, but handles it differently for bizarre reasons.)
Right, thanks.
> Personally, I think the two-level namespace feature is the opposite of
I am documenting this behavior in the CREATE VIEW manual page, diff
attached.
---
Gaetano Mendola wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >
On Fri, 26 Sep 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Perhaps we can throw a warning rather than an error, and adjust initdb
> > to be consistent.
>
> I like the idea of reducing the newline consistency check to a warning.
> There is one thing we'd have to watch fo
On Fri, 26 Sep 2003, Tom Lane wrote:
> I was chewing this over with Bruce on the phone just now, and we refined
> the idea a little. Some errors (primarily those detected inside the
> datatype input procedures) can be clearly traced to a specific column,
> whereas others (such as too many fields
Jon Jensen wrote:
> On Fri, 26 Sep 2003, Tom Lane wrote:
>
> > I was chewing this over with Bruce on the phone just now, and we refined
> > the idea a little. Some errors (primarily those detected inside the
> > datatype input procedures) can be clearly traced to a specific column,
> > whereas ot
I just noticed that libpq/ecpg use $(THREAD_CFLAGS) as part of CPPFLAGS.
(I added that code.)
Is that correct? Should it be added to CFLAGS instead?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a ha
1 - 100 of 118 matches
Mail list logo