Excessively long values are currently silently truncated when they are
inserted into char or varchar fields. This makes the entire notion of
specifying a length limit for these types kind of useless, IMO. Needless
to say, it's also not in compliance with SQL.
To quote Tom
Thus spake The Hermit Hacker
all 77 databases got dump'd as the same database:
Personally I never use pg_dumpall. It is easy to write a script to get
the list of databases and use pg_dump to dump them individually. In fact
I like dumping individual tables if I can. Mostly I like the ability
At 01:09 11/04/01 +0200, Peter Eisentraut wrote:
Btw., it would really seem like a neat feature if a given pg_dump suite
would also handle the respective previous version.
This has been in the back of my mind for some time, and is why I initially
backported my pg_dump changes to 7.0.
At 06:27 11/04/01 -0400, D'Arcy J.M. Cain wrote:
Finding and fixing one 7 row table
in a multi-gigabyte files really sucks. :-)
At least in 7.1 you can dump the who DB to a file/tape, then extract one
table from the dump file easily...
I just tested a bug I originally fount in 7.1b4 with the new 7.1RC3 and it
still exists. I would consider this a major bug because I know of no work
around.
Basically what happens is that a dump of an existing Unicode database (from
7.03) has a double-byte hyphen character that becomes \255 in
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
What about going the other way around... Promote the int2 to an int4
(lossless). Actually for all int1,int2 datatypes (regardless of whether it
was the constant or the column) you could promote all to a common int4 and
then do comparisons.
That is why the index is not used: the backend is
Philip Warner writes:
At 01:09 11/04/01 +0200, Peter Eisentraut wrote:
Btw., it would really seem like a neat feature if a given pg_dump suite
would also handle the respective previous version.
This has been in the back of my mind for some time, and is why I initially
backported my
At 17:18 11/04/01 +0200, Peter Eisentraut wrote:
What I meant was that whenever the backend changes in a way that mandates
pg_dump changes we would leave the old way in place and only add a new
case to handle the new backend.
That's what I had in mind as well; I gave up on the backport because
I notice that the docs have commented-out all mention of the age()
functions, with the note that "These two functions don't seem to do what
it says here, or anything reasonable at all for that matter."
??
How did we conclude that, and how could these be confusing? I do not
recall any discussion
Hi,
Just 2 questions.
1. Does kerberos work with PGSql 7.1rc4? I tried it today without success...
Anyone got it working? With MIT? With win2k ADS?
2. When will 7.1 be released. (apporx :-) )
Thanks
-jec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Jean-Eric Cuendet
Linkvest SA
Av
grumble
http://www.postgresql.org/mhonarc/pgsql-hackers/2001-02/msg00550.html
OK, so that narrows down the list of suspects ;)
Why do you have a problem with the age() function? It *does* behave
differently than date subtraction, as explicitly mentioned in the docs
(preserving years, etc
Thomas Lockhart writes:
I notice that the docs have commented-out all mention of the age()
functions, with the note that "These two functions don't seem to do what
it says here, or anything reasonable at all for that matter."
??
How did we conclude that, and how could these be confusing?
Thomas Lockhart writes:
Why do you have a problem with the age() function? It *does* behave
differently than date subtraction, as explicitly mentioned in the docs
(preserving years, etc etc).
As you see in one of the examples I posted, it does not preserve years and
months. What exactly
There are several ways to solve the problem:
1. Convert to common numeric format for all numbers, ala Oracle
2. Promote for comparison during the index scan
3. Promote index boundary values for comparison in query planner only
Convert back to index column type for actual scan
Option 1
Roberto Mello suggested I post my problem here. He suggested Tom Lane
might take a look...
I dumped an 7.0.3 database and restored that to rc2, which went fine after
a bit of reordering help (It was an OpenACS table set).
Now when I dump the same database with rc2 (or 4) I get a
different set
At 18:53 11/04/01 +0200, Pascal Scheffers wrote:
I have a copy
of the relevant dumps (both the initial 7.0.3 7.1rc2 and the rc4 rc4
dump), anyone interested may have them for testing.
Yes please.
Philip Warner
Thomas Lockhart writes:
Why do you have a problem with the age() function? It *does* behave
differently than date subtraction, as explicitly mentioned in the docs
(preserving years, etc etc).
As you see in one of the examples I posted, it does not preserve years and
months. What
Lamar Owen writes:
One quick note -- since 'R' 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
Btw., are you aware
Zeugswetter Andreas SB writes:
Thank you. Is an "exception condition" necessarily an error, or
is a warning also an exception condition ?
A warning/notice is called a "completion condition".
Because other db's only raise a warning. Of course we don't want to
copy that behavior if they are
Hmm. I'm pretty sure that a single index on the entire contents of a
resume *as a single field* is close to useless. And an index on an 8k
piece is also useless. Presumably you really want an index covering each
significant word of each resume, in which case you would not run into
the 4k
Peter Eisentraut wrote:
Lamar Owen writes:
One quick note -- since 'R' 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already
Lamar Owen wrote:
Last time I looked at the documentation for the serial tag, its use was
strongly discouraged. But that _has_ been awhile -- maybe it could be
useful. But I would prefer the whole version numbering thingtobe fixed,
as the Debian packages have the same issue -- and I
Oliver Elphick wrote:
Lamar Owen wrote:
as the Debian packages have the same issue -- and I don't know if .deb
has an analog to Serial:.
We have epochs, that is, the package version is preceded by an integer
and a colon, which overrides every other part of the version and release
Lamar Owen writes:
Yes, I am, actually. But it seems a broken way of dealing with it.
Although I do have another idea, thanks to Trond. Rather than package
'7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
versioning. I could progress from '7.1-0.1beta1.1' through
As you see in one of the examples I posted, it does not preserve years and
months. What exactly does that mean anyway? Simple subtraction also
preserves years and months, as I see it.
OK, so there is a documentation problem, since the functions do exactly
what they claim!
What do you mean
Peter Eisentraut wrote:
Lamar Owen writes:
Yes, I am, actually. But it seems a broken way of dealing with it.
Although I do have another idea, thanks to Trond. Rather than package
'7.1RC4-1' I could package '7.1-0.1RC4' -- giving a straight
versioning. I could progress from
I will be doing an OS upgrade, tomorrow, Thursday, so will be
unavailable for a while. TODO.detail and my web site will be down at
that time as well.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a
I was trying to make a minor change today to the gram.y file to make
PostgreSQL recognize "DOUBLE" as a data type the way DB2 does. I ran into
reduce / reduce conflicts using both of the methods I tried.
Having fought extensively with Bison before on a SQL oriented language
Bruce Momjian wrote:
Interesting. What advantages would there be?
As any one who has ever attempted to build a C++ parser using Yacc or Bison
can attest, it is very difficult to get an LALR based parser to correctly
parse a sophisticated grammar. The advantages of using a hand written
Mark Butler [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Interesting. What advantages would there be?
As any one who has ever attempted to build a C++ parser using Yacc or Bison
can attest, it is very difficult to get an LALR based parser to correctly
parse a sophisticated grammar.
31 matches
Mail list logo
