AW: AW: [HACKERS] Truncation of char, varchar types
> > > 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 "paragraph and verse please" :-) > > SQL 1992, 9.2 GR 3 e) > > """ > If the data type of T is variable-length character string and > the length in characters M of V is greater than the maximum > length in characters L of T, then, > > Case: > > i) If the rightmost M-L characters of V are all s, then > the value of T is set to the first L characters of V and > the length in characters of T is set to L. > > ii) If one or more of the rightmost M-L characters of V are > not s, then an exception condition is raised: data > ^ > exception-string data, right truncation. > """ Thank you. Is an "exception condition" necessarily an error, or is a warning also an exception condition ? > Similarly in SQL 1999 and for other data types. > > > > How do people feel about changing this to raise an error in this > > > situation? > > > > Can't do. > > Why not? Because other db's only raise a warning. Of course we don't want to copy that behavior if they are not conformant. See above question. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't importto v7.1?
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 to fix one table if there is a problem. Finding and fixing one 7 row table in a multi-gigabyte files really sucks. :-) -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
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. Unfortunately, I did not continue, and the backport wa targetted at 7.0, not 7.1. I would be willing to try to get a 7.0 compatibility mode going, perhaps as a patch/contrib after 7.1 (or before, depending on release). There is probably not that much effort involved; the main changes to the DB interface are in the use of formatType and the function manager defintions - at least I think that's the case... Peter: what options are there for getting formatType working in 7.0? Also, just in case people can think of other dump-related changes from 7.0, to 7.1, I have included a list below: - LOs stored differently (one or two line change) - formatType (a few places, but it's significant) - function manager (SQL substitution should work here, I hope, since the fmgr can detect the right protocol to use) - detection of relations that are views - old isViewRule would need to be resurrected - last builtin OID derivation changed - Handling of ZPBITOID & VARBITOID types? Not sure if this is OK for 7.0 Unfortunately, I have not paid much attention to internal changes from 7.0 to 7.1, so I have no idea what else was changed. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
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... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Indexes not used in 7.1RC4: Bug?
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 case, >we must demote a constant assigned as "int4" by the parser into an >"int2" to be directly comparable to the indexed column. We could >probably do this with some hack code as a brute-force exercise, but no >one has yet bothered (patches welcome ;) But in general, we must handle >the case that the specified constraint is *not* directly convertible to >the indexed type (e.g. is out of range) even though this would seem to >reduce to a choice between a trivial noop or a sequential scan of the >entire table. If we can do this without cluttering up the code too much, >we should go ahead and do it, but it has apparently been a low priority. 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. Promoting all to int8 and then doing a comparison would be excessively slow. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can'timport to v7.1?
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 -- > > Was there an error message during restore? > > I've been dumping/restoring w/7.1 since long before beta, w/o real > problems, but haven't been doing this w/7.0.3 stuff. But still, psql > should give you some error messages. > > (I'm sure you know this, but for the benefit of others on the list) > In Linux, I usually use the command) > >psql dbname < dumpfile 2>&1 | grep ERROR > > so that I don't miss any errors among the all the NOTICEs I recall having a problem when Marc moved the server away from hub.org and to db.hub.org. I couldn't import the database I exported from 7.0.x into it without first creating the sequences. Could this be something related - although I thought that had gotten fixed. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: Indexes not used in 7.1RC4: Bug?
> 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 promoting all of the int2 column values to int4 for the comparison, and concludes that the available index is not relevant. The index traversal code would need to know how to promote individual values in the index for comparison, which is an interesting idea but I haven't thought about how efficient it would be. Clearly the cost would be different than a simple comparison. - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can'timport to v7.1?
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 pg_dump changes to 7.0. Unfortunately, I did not continue,
> and the backport wa targetted at 7.0, not 7.1.
This is not really what I had in mind. Backporting enhancements would
only serve the users that manually installed the enhancements. Actually,
it's quite idiosyncratic, because the point of a new release is to publish
enhancements.
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. Stupid example:
switch (backend_version)
{
case 71:
result = PQexex("select * from pg_class;");
break;
case 72:
result = PQexec("select * from pg_newnameforpgclass;");
break;
}
This would invariably introduce code bloat, but that could probably be
managed by a modular design within pg_dump, plus perhaps removing support
for really old versions once in a while.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
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 it seemed pointless (as you suggest). > >This would invariably introduce code bloat, but that could probably be >managed by a modular design within pg_dump, plus perhaps removing support >for really old versions once in a while. I was thinking that with time these version-specific cases will reduce (eg. definition schemas will help), and that we could put all the DB interface into separate modules. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] age() function documentation
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 on the topic, and I'll restore the documentation until someone can refresh my memory on why these are a problem. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Postgres & Kerberos
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 Baumettes 19, 1020 Renens Switzerland Tel +41 21 632 9043 Fax +41 21 632 9090 http://www.linkvest.com E-mail: [EMAIL PROTECTED] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] age() function documentation
> > > 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). Would we like some additional clarification in the docs perhaps? Seems to be preferable to dropping all mention, especially since it is a useful function. - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] age() function documentation
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? I do not > recall any discussion on the topic, and I'll restore the documentation > until someone can refresh my memory on why these are a problem. > > http://www.postgresql.org/mhonarc/pgsql-hackers/2001-02/msg00550.html -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] age() function documentation
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 does that mean anyway? Simple subtraction also preserves years and months, as I see it. > Would we like some additional clarification in the docs perhaps? Seems > to be preferable to dropping all mention, especially since it is a > useful function. By all means. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Index type promotion
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 solve the general problem, has a space / performance penalty, and would be a major change. Option 2 involves making serious changes to every index access method, and also has a performance penalty. Option 3 appears to me to be the way to go. The main general requirement is method similar to typeInheritsFrom() in backend/parser/parse_func.c to determine whether a true promotion is possible for a pair of non-complex data types. One thing I am not clear on is how much re-planning is done when a query is executed with different parameter values. If re-planning is not done, is it acceptable to make minor plan changes according to the parameter values? For example, it would be necessary to change a "<" operator to a "<=" operator to get proper index scan behavior on a smallint index if the original right hand side was greater than 32767. - Mark Thomas Lockhart wrote: > That is why the index is not used: the backend is promoting all of the > int2 column values to > int4 for the comparison, and concludes that the available index is not > relevant. > > The index traversal code would need to know how to promote individual > values in the index for comparison, which is an interesting idea but I > haven't thought about how efficient it would be. Clearly the cost would > be different than a simple comparison. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] pg_dump ordering problem (rc4)
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 ordering problems. Some five functions are used in views before their definitions. In the original (7.0) dump they were in the correct order, but rc2/4 (the only ones I tried) got it wrong. The original OIDs for the functions in the 7.1 dump are lower than those of the views. I do not know what is wrong. I can reproduce the results on another box. 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. I compiled on a fairly clean RH6.2/AMD-K6/256M box with nothing more than ./configure; make; make install (so that it ended up in /usr/local/pgsql) The box has the 7.0.3 RPMs installed, 7.1 runs on port 5433 and has a separate postmaster account (postgr71). Regards, Pascal Scheffers. -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT$/MU/ED/S/P d(++) s+:+ a?(-) C++ UL P+(--) L+++ E(++) W+++ N++ o? K w++$(---) O- M-- V-- PS@ PE Y+(-) PGP(++) t+@ 5++ X- R tv b++ DI@ D? G e++ h---(-/) y+++ --END GEEK CODE BLOCK-- co-hosting is for sissies. get your own machine out there. NOW! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump ordering problem (rc4)
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| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] age() function documentation
> 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 does that mean anyway? Simple subtraction also > preserves years and months, as I see it. >From your URL email, this one seems to work: select age(date '1999-05-17', date '1957-06-13'); age --- 41 years 11 mons 3 days 23:00 (1 row) This one did not: peter=# select date '1999-08-13' - date '1999-06-13'; ?column? -- 61 (1 row) and this one is less than one month: peter=# select age(date '1999-05-17', date '1999-06-13'); age -- -27 days (1 row) I will admit age() is a little confusing, but it seems to work as intended. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
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 of the 'serial' tag to override the version guessing mechanism? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AW: AW: [HACKERS] Truncation of char, varchar types
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 not conformant. See above question. Someone said Oracle raises an error. Informix seems to be the only other db that truncates silently. I think Oracle wins here... -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Speaking of Indexing... (Text indexing)
> 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 limit (or 2k limit? it is documented somewhere) on the size of an > *index* field (which is still a limitation on PostgreSQL built with the > standard 8k block size. Of course, you can build with a larger block > size). Just an FYI.. I asked the other day and someone (Tom?) told me it was about 2k.. -Mitch ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
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 installed. > > Btw., are you aware of the 'serial' tag to override the version guessing > mechanism? 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.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'. 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 don't know if .deb has an analog to Serial:. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
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 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 number. However, if I ever use an epoch, I will be stuck with epochs for ever; so I don't want to start. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Is any one of you in trouble? He should pray. Is anyone happy? Let him sing songs of praise. Is any one of you sick? He should call the elders of the church to pray over him...The prayer of a righteous man is powerful and effective." James 5:13,14,16 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
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 > number. However, if I ever use an epoch, I will be stuck with epochs for ever; > so I don't want to start. RPM also has the epoch mechanism -- and it sounds just like what you have just described. Not something I want to start using, either. It's more like a 'super-major' version number than the RPM serial mechanism, which works in a more broken fashion. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
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.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'. Just name them 7.1betax 7.1rcx 7.1.0 7.1.1 etc. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] age() function documentation
> 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 by "it does not preserve years and months"? I look at
the same example, and run the same example here, and it does exactly
what I would expect, in the way I described it in the docs ;)
> > Would we like some additional clarification in the docs perhaps? Seems
> > to be preferable to dropping all mention, especially since it is a
> > useful function.
> By all means.
OK, I'll add some info. But assuming that we are just missing a clear
definition of what "preserves years and months" means, here it is:
Typical date/time arithmetic resolves to an absolute time or interval.
In those cases, *qualitative* quantities such as years and months are
resolved to a specific absolute interval at the time of calculation.
The age() functions *preserve* the qualitative fields year and month. So
you see the difference in results:
lockhart=# select age('today', '1957-06-13');
-
43 years 9 mons 28 days
lockhart=# select timestamp 'today' - timestamp '1957-06-13';
16008 days
In the case for the DATE type, the result is an integer value (not an
interval) which I believe was done intentionally but I'm not recalling
exactly why; I can research it if necessary:
lockhart=# select date 'today' - date '1957-06-13';
--
16008
returns the number of days (which is also an absolute, quantitative
time).
- Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
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.1-0.1beta1.1' through > > '7.1-0.1beta6.2' through '7.1-0.2RC1.1' to '7.1-1'. > Just name them > 7.1betax > 7.1rcx > 7.1.0 > 7.1.1 And I like that -- but that would be Marc's (and the core group) decision to make not mine. If the current schema is continued, I can work around it --but it would be nice if the version numbering could be more packager-friendly. I have a real aversion to naming the RPM version number differently from the main package version. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Machine down
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 hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Yacc / Bison difficulties
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 project, I am amazed that you were able to get a grammar as complex as PostgreSQL to work without major difficulty. I was wondering about what the sense of the list would be to someday accepting a rewrite using a hand-coded LL(k) recursive descent parser. Anyone? - Mark Butler ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Yacc / Bison difficulties
> > 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 project, I am amazed that you were able to get a grammar as > complex as PostgreSQL to work without major difficulty. > > I was wondering about what the sense of the list would be to someday accepting > a rewrite using a hand-coded LL(k) recursive descent parser. Anyone? Interesting. What advantages would there be? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Hand written parsers
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 recursive descent parser lie in four areas: 1) ease of implementing grammar changes 2) ease of debugging 3) ability to handle unusual cases 4) ability to support context sensitive grammars Context sensitivity is useful for handling things like embedded programming languages without having to escape whole procedures as string literals, for example. We could support procedural language plugins without the current limitations on syntax. Another nice capability is the ability to enable and disable grammar rules at run time - you could add run time options to disable all non SQL-92 grammar rules for application portability testing or emulate Oracle's outer join syntax, as a couple of examples. - Mark Butler ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Hand written parsers
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. The advantages of using a hand written > recursive descent parser lie in four areas: > > 1) ease of implementing grammar changes > 2) ease of debugging > 3) ability to handle unusual cases > 4) ability to support context sensitive grammars > > Context sensitivity is useful for handling things like embedded programming > languages without having to escape whole procedures as string literals, for > example. We could support procedural language plugins without the current > limitations on syntax. > > Another nice capability is the ability to enable and disable grammar rules at > run time - you could add run time options to disable all non SQL-92 grammar > rules for application portability testing or emulate Oracle's outer join > syntax, as a couple of examples. On the other hand, recursive descent parsers tend to be more ad hoc, they tend to be harder to maintain, and they tend to be less efficient. I believe that yacc based parsers support context sensitivity just as well as recursive descent parsers. I'm not sure that C++ is a fair example. The problem with parsing C++ is the result of a convoluted declaration syntax, so much so that some constructs are completely syntactically ambiguous no matter how you look at them and must be decided by semantic rules. It's true that in such a case recursive descent is easier, because it is easier to mix semantic rules and syntax rules. But the SQL syntax is much simpler; is this really a problem with SQL? And I note that despite the difficulties, the g++ parser is yacc based. Ian ---(end of broadcast)--- TIP 462: A mushroom cloud has no silver lining. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
