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
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
recurs
>
> 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
> tra
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
translation proje
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 h
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 '7.
> 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 mea
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
> '7.1-0.1b
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 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 d
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
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 a
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 a
> 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.
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
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 of
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 doesn't
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 d
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 confu
> >
> 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 etc). Wo
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 des
> 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
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
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 beca
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
> 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 i
On Tue, 10 Apr 2001, Joel Burton wrote:
> On Tue, 10 Apr 2001, The Hermit Hacker wrote:
>
> > all I did was use pg_dumpall from v7.0.3 to dump to a text file, and
> > "psql template1 < dumpfile" to load it back in again ...
> >
> > obviously this doesn't work like it has in the past?
>
> Marc --
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
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...
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. Unfort
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
> > > 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
32 matches
Mail list logo
