Re: [HACKERS]
> > My vote is "tough, time to fix your SQL code". > Sounds good to me, but please document it in the "migration" notes. No need for a surprise. Regards, Jeff ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] 7.3beta and ecpg
On Thu, Sep 12, 2002 at 03:18:13PM -0400, Tom Lane wrote: > Sure --- and that is exactly *not* what the backend facility does. In > the backend PREPARE you supply the statement to be prepared directly in > the same SQL command, not as the value of some variable. The variable will be replaced by ecpg. That's not a problem. The actual ecpg prepare function does insert the value of the variable when storing the so-called prepared statement, which of course is not prepared in reality. > > Now if you have a parameter in the prepared statement by just specify > > "?" instead some value, you add a using clause during execution to set > > the values. > > And a plain "?" isn't going to fly as the parameter marker, either. > The backend wants to know what datatype each parameter is supposed to > be. So, yes, this may be a problem we have to think about. But I could handle that by asking the backend for the datatypes before issuing the PREPARE statement and thus formulating it accordingly. Anyway, we could of course keep both ways seperate, but right now that would mean I have to disable access to the backend functions in ecpg or else the parser will be in trouble or else the parser will be in trouble. And frankly I don't really like that. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] failed Assert() in utf8_and_iso8859_1.c
> Hmm, looks like all the conversion_procs files have > > Assert(len > 0); > > Surely that should be Assert(len >= 0)? > > I also notice that I neglected to change PG_RETURN_INT32(0) to > PG_RETURN_VOID() in these files. That's only cosmetic, but > probably it should be done. Fixed. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> escribió: >> Actually, there might not be a problem. c1.name can't be deleted until >> both p1.name and p2.name go away, and at that point we want both c1.name >> and gc1.name to go away. So as long as we don't *recursively* decrement >> the inherits count when c1.name.attisinherited hasn't reached 0, this >> might be okay. But it needs thought. > This is what I implemented on the patch I posted, I think. The idea is > that attisinherited is decremented non-recursively, i.e. only in direct > inheritors; and when it reaches zero the column is dropped, and its > inheritors have it decremented also. Yeah; after marginally more thought, I'm thinking that the correct definition of attisinherited (need new name BTW) is "number of *direct* ancestors this table inherits this column from". I think you are describing the same idea. Given the obvious algorithms for updating and using such a value, does anyone see a flaw in the behavior? One corner case is that I think we currently allow create table p (f1 int); create table c (f1 int) inherits(p); which is useless in the given example but is not useless if c provides a default or constraints for column f1. ISTM f1 should not go away in c if we drop it in p, in this case. Maybe we want not an "inherits count" but a "total sources of definitions count", which would include 1 for each ancestral table plus 1 if declared locally. When it drops to 0, okay to delete the column. > however, I haven't proven it is. Multiple inheritance and > multiple generations is weird. What he said... I'm way too tired to think this through tonight... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] An opportunity to prove PostgreSQL and our requirement of Case Study info
Hi everyone, An interesting development. Afilias and LibertyRMS, the people who've been happily running the .info namespace on PostgreSQL servers, are the technical backend of the ISOC application for management of the .org namespace. However, ICANN is asking for more detail about the backend database, to prove it is an "appropriate choice for a mission critical applications". In particular, ICANN wants proof that other companies are using PostgreSQL for Mission Critical things. The Oracle/DB2/Sybase/etc guys have an advantage here because they already have a bunch of case studies prepared and we're only beginning to get these together. Afilias and LibertyRMS are looking to pull as much relevant info together as possible and prove beyond a shadow of a doubt that PostgreSQL is up to the task, in time for their presentation on Saturday. The kind of thing they're after is stuff that executives will be interested in. i.e. Case Studies and examples of other businesses running PostgreSQL happily for Mission Critical stuff, under high load, and getting support when they need it, etc. The questions that ICANN have asked are online here: http://www.icann.org/tlds/org/questions-to-applicants-13.htm As you can see there is only a 2 day timeframe in which Afilias & LibertyRMS can get the info they need together, including today, so there's not much time. The details of the ISOC application itself is online here if anyone is interested: http://www.icann.org/tlds/org/applications/isoc/ A point to make clear is this is not in any way an endorsement of their application. Some of the other places bidding also have significant interests in PostgreSQL. The only thing we're interested in here is showing off that PostgreSQL itself is up to the task. Can people please come forward to help them out with info about the reliability and performance of PostgreSQL in Mission Critical situations? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] btree page merging
Alvaro Herrera <[EMAIL PROTECTED]> writes: > What I want to know is how different from B+-trees are PostgreSQL > B-trees; PG's "btrees" are in fact B+-trees according to the more formal academic notation. IIRC the + just indicates allowing any number of keys/downlinks in an internal tree node. I've read the README in src/backend/access/nbtree/, and it > indicates some areas in which they are different from B-Trees (Lehmann > and Yao's?). The L-Y paper omits some details, and it makes some unrealistic assumptions like all keys being the same size. nbtree/README is just trying to tell you how we filled in those holes. It's not really a new algorithm, just L-Y brought from academic to production status. > I'm not used to searching for this kind of things, and ACM won't let me > in (althought my university has a subscription, I can't get any papers > on SIGMOD). Complain --- I have half a dozen btree-related papers stashed that I got from ACM's online library. They are an essential resource. BTW, SIGMOD is presently selling DVDs with every durn paper they ever published for the last couple or three decades. I was fortunate enough to get a set for US$25 when I went to their conference this summer. The price for non-members is about triple that, but it's still a steal. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS]
En Fri, 13 Sep 2002 00:46:00 -0400 Tom Lane <[EMAIL PROTECTED]> escribió: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > > Sure it is. The float=>int casts need to be made implicit, or we'll have > > tons of problems like this. > > Well, yeah. That did not seem to bother anyone last spring, when we > were discussing tightening the implicit-casting rules. Shall we > abandon all that work and go back to "any available cast can be applied > implicitly"? Implicit float to int loses precision, so it shouldn't be implicit, should it? Maybe the solution is to make 7.3 pg_dump smart enough to add explicit casts where default values demand them... Is this possible? Are there other cases where tightening implicit casts is going to bit users? -- Alvaro Herrera () El sentido de las cosas no viene de las cosas, sino de las inteligencias que las aplican a sus problemas diarios en busca del progreso. (Ernesto Hernández-Novich) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS]
> Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Bruce Momjian writes: > >> I would love to say that this is related to change in casts, but that > >> isn't the case. > > > Sure it is. The float=>int casts need to be made implicit, or > we'll have > > tons of problems like this. > > Well, yeah. That did not seem to bother anyone last spring, when we > were discussing tightening the implicit-casting rules. Shall we > abandon all that work and go back to "any available cast can be applied > implicitly"? > > My vote is "tough, time to fix your SQL code". Wasn't the resolution back then to "wait until beta and see who complains"? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
En Thu, 12 Sep 2002 23:40:21 -0400 Tom Lane <[EMAIL PROTECTED]> escribió: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > If this is not clear, imagine the following situation: > > > create table p1(id int, name text); > > create table p2(id2 int, name text); > > create table c1(age int) inherits(p1,p2); > > create table gc1() inherits (c1); > > > p1 and p2 have name->attisinherited=0, while c1 has > > name->attisinherited=2. But gc1->name->attisinherited=1. > > We could probably cause gc1->name->attisinherited to be 2 in this > scenario; does that help? I'm trying to imagine a case where this is harmful, but cannot find any. It would have to be proven that there is none; IMHO this is a little deviating from the "reality". > Actually, there might not be a problem. c1.name can't be deleted until > both p1.name and p2.name go away, and at that point we want both c1.name > and gc1.name to go away. So as long as we don't *recursively* decrement > the inherits count when c1.name.attisinherited hasn't reached 0, this > might be okay. But it needs thought. This is what I implemented on the patch I posted, I think. The idea is that attisinherited is decremented non-recursively, i.e. only in direct inheritors; and when it reaches zero the column is dropped, and its inheritors have it decremented also. In the cases I've tried this works, and it seems to me that it is correct; however, I haven't proven it is. Multiple inheritance and multiple generations is weird. It just ocurred to me that maybe I overlooked the ALTER TABLE ONLY ... DROP COLUMN case, but I'm now going to bed. I'll think about this case tomorrow. > > I see this is getting away from the "trivial fix" camp. > > Yup. Let's step back and think carefully before we plunge into the > coding. What goes away when, and how do we define the inherits-count > to make it work right? Huh, I already did. Please think about my solution. -- Alvaro Herrera () "Para tener mas hay que desear menos" ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS]
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Bruce Momjian writes: >> I would love to say that this is related to change in casts, but that >> isn't the case. > Sure it is. The float=>int casts need to be made implicit, or we'll have > tons of problems like this. Well, yeah. That did not seem to bother anyone last spring, when we were discussing tightening the implicit-casting rules. Shall we abandon all that work and go back to "any available cast can be applied implicitly"? My vote is "tough, time to fix your SQL code". regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] btree page merging
Hello! I recommend two good sources of information in English: http://www.nist.gov/dads/ further look for balanced trees and kins (BTW, there is some other interesting algorithms alike patricia). and well-known Donald Knuth's monography, namely, volume 3. (I mean "The Art of Computer Programming".) its description can be found at http://www-cs-faculty.stanford.edu/~knuth/taocp.htm You can also look at how MUMPS (where B+trees is the "heart" of DBMS) handles B+trees if curious: http://math-cs.cns.uni.edu/~okane/cgi-bin/newpres/index.cgi?array=lib&ml=2&a1=1002+Mumps+Language+Research&a2=1011+The+Mumps+Language -- WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group. Phone: +7 (3832) 106228, ext.140, E-mail: [EMAIL PROTECTED] Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
Philip Warner <[EMAIL PROTECTED]> writes: > ISTM that this problem comes about because we allow an external function to > be defined incorrectly (ie. the db says it returns type A, the function > really returns type B) - and we should be addressing that problem. Well, yeah. 7.3 is trying to tighten up on exactly that point. And our current problem arises precisely because dumps from older database versions will fail to meet the tighter rules. How can we accommodate those old dumps without abandoning the attempt to be tighter about datatypes? regards, tom lane ---(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] OPAQUE and 7.2-7.3 upgrade
Philip Warner <[EMAIL PROTECTED]> writes: > At 11:27 PM 12/09/2002 -0400, Tom Lane wrote: >> You mean hardwire the names "plpgsql_language_handler", etc, as being >> ones that should return such-and-such instead of OPAQUE? > No; I actually mean modifying the function definition macros > (PG_FUNCTION_INFO etc) to allow function definitions to (optionally) > include return type (at least for builtin types with fixed IDs) - they > already define the invocation method etc, so it does not seem a big stretch > to add a return type ID. That cannot work for user-defined functions, wherein the datatype OID is not frozen at the time the code is compiled. In any case, it surely does not help for our current problem, which is forward-compatibility of dumps from 7.2 databases... regards, tom lane ---(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] OPAQUE and 7.2-7.3 upgrade
At 01:42 PM 13/09/2002 +1000, Philip Warner wrote: >Not all functions would need to use these, but when a user defines a >function they could be checked. And in the case of the plpgsql handlers, >they would of course be defined. ISTM that this problem comes about because we allow an external function to be defined incorrectly (ie. the db says it returns type A, the function really returns type B) - and we should be addressing that problem. As I said in an earlier post, it might be good in the future to apply this to function args as well. 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 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] btree page merging
Hackers, I'm starting to read the existing algorithms for btree index shrinking. Right now I'm at 1996 SIGMOD proceedings, Zou and Salzberg "On-line Reorganization of Sparsely-populated B+-trees". What I want to know is how different from B+-trees are PostgreSQL B-trees; I've read the README in src/backend/access/nbtree/, and it indicates some areas in which they are different from B-Trees (Lehmann and Yao's?). But I don't really know how B-Trees are different from B+-Trees (is my ignorance starting to show?). Where can I read about that? Also, Tom said some time ago that there is some literature on the concurrent page merging camp. I haven't been able to found anything else than the proceedings I have right now... is there something else? I'm not used to searching for this kind of things, and ACM won't let me in (althought my university has a subscription, I can't get any papers on SIGMOD). Thank you, -- Alvaro Herrera () "Un poeta es un mundo encerrado en un hombre" (Victor Hugo) ---(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] OPAQUE and 7.2-7.3 upgrade
At 11:27 PM 12/09/2002 -0400, Tom Lane wrote: >You mean hardwire the names "plpgsql_language_handler", etc, as being >ones that should return such-and-such instead of OPAQUE? No; I actually mean modifying the function definition macros (PG_FUNCTION_INFO etc) to allow function definitions to (optionally) include return type (at least for builtin types with fixed IDs) - they already define the invocation method etc, so it does not seem a big stretch to add a return type ID. Not all functions would need to use these, but when a user defines a function they could be checked. And in the case of the plpgsql handlers, they would of course be defined. 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]
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
Alvaro Herrera <[EMAIL PROTECTED]> writes: > If this is not clear, imagine the following situation: > create table p1(id int, name text); > create table p2(id2 int, name text); > create table c1(age int) inherits(p1,p2); > create table gc1() inherits (c1); > p1 and p2 have name->attisinherited=0, while c1 has > name->attisinherited=2. But gc1->name->attisinherited=1. Ick. I hadn't thought that far ahead. We could probably cause gc1->name->attisinherited to be 2 in this scenario; does that help? Actually, there might not be a problem. c1.name can't be deleted until both p1.name and p2.name go away, and at that point we want both c1.name and gc1.name to go away. So as long as we don't *recursively* decrement the inherits count when c1.name.attisinherited hasn't reached 0, this might be okay. But it needs thought. > I see this is getting away from the "trivial fix" camp. Yup. Let's step back and think carefully before we plunge into the coding. What goes away when, and how do we define the inherits-count to make it work right? regards, tom lane ---(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] OPAQUE and 7.2-7.3 upgrade
Philip Warner <[EMAIL PROTECTED]> writes: > At 01:37 PM 12/09/2002 -0400, Tom Lane wrote: >> Er ... what has that got to do with this? > When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return > type, and create it with the correct return type (with warning). We just > need to make sure that the language handlers are listed as returning the > correct type. You mean hardwire the names "plpgsql_language_handler", etc, as being ones that should return such-and-such instead of OPAQUE? I suppose that's a possible approach, but it strikes me as mighty ugly. If we were going to do such a thing, I'd also want to see it force the shlib path to "$libdir". Does that strike you as impossibly crocky, or a reasonable workaround for our past sins? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
En 12 Sep 2002 17:23:41 +0200 Hannu Krosing <[EMAIL PROTECTED]> escribió: > The other sad thing about the current behaviour is that in addition to > being wrong it also breaks dump/reload - after dump/reload the initially > dropped column is back in c1. I hadn't read this paragraph before. But I don't understand what you're saying. If I drop the column from p1 but not from p2, how is it expected that the column doesn't show in c1, that inherits both? Truth is that the column shouldn't have disappeared in the first place, so it isn't a mistake that shows up in the dump. Sure, databases before and after the dump are different, but the one before dump is broken. I don't have the original pgsql version (without the patch) compiled right now, but I think that if you were to select from p2, the backend would crash (or at least elog(ERROR)). Anyway, the patch I just submitted should fix this bug. Please test it and thanks for the report. -- Alvaro Herrera () "La conclusion que podemos sacar de esos estudios es que no podemos sacar ninguna conclusion de ellos" (Tanenbaum) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
Tom Lane dijo: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > > The count approach seems definitely the right way, but a check (possibly > > a slow one) can be probably done without initdb. > > Slow, complicated to code, and deadlock-prone (since you'd have to > acquire locks on the other parent tables). My feeling is we fix this > with a counted attisinherited field, or don't fix at all. All right, I now have all the catalog changes on place; this is the easy part (is an int2 count enough?). But when actually dropping a column, the recursion cannot be done the way it's done now, fetching the whole inheritor tree in one pass, because there's no way to distinguish the direct ones that have the attisinherited count greater than 1 from deeper ones; it has to be done step by step. If this is not clear, imagine the following situation: create table p1(id int, name text); create table p2(id2 int, name text); create table c1(age int) inherits(p1,p2); create table gc1() inherits (c1); p1 and p2 have name->attisinherited=0, while c1 has name->attisinherited=2. But gc1->name->attisinherited=1. If I just recurse the tree the way it's done now, I will happily drop "name" from gc1 while keeping it on c1. So I have to switch from find_all_inheritors() to find_inheritance_children() and keep recursing until there are no more inheritors (I still have to check if there are other gotchas with this approach, or optimizations to be done). I am already midway with this, but wanted to let you know in case the patch is rejected. Is this Ok? I see this is getting away from the "trivial fix" camp. -- Alvaro Herrera () "The Gord often wonders why people threaten never to come back after they've been told never to return" (www.actsofgord.com) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FreeBSD Packages/Port for 7.3beta1...
> Setting locales (LC_ALL) is now best done as an option to initdb. Be sure > to update pkg-message to that effect. Also, the encoding should be > specified to initdb (rather than configure --enable-multibyte=ENCODING). I guess --enable-multibyte=ENCODING does nothing with 7.3 -- Tatsuo Ishii ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
At 01:37 PM 12/09/2002 -0400, Tom Lane wrote: > > What about extending the function manager macros to know about return > types > > (at least for builtin types)? > >Er ... what has that got to do with this? When a user issues a 'CREATE FUNCTION' call, the fmgr can check the return type, and create it with the correct return type (with warning). We just need to make sure that the language handlers are listed as returning the correct type. 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]
Re: [HACKERS] TOAST docs
On Fri, 13 Sep 2002, Peter Eisentraut wrote: > Alvaro Herrera writes: > > > Is there some documentation on TOAST? > > No. Why do you need any? I think I saw some docs in the /usr/local/src/postgresql-7.2.1/src/backend/access/heap/tuptoaster.c file on my box. :-) Actually it is pretty well commented, so I'm not just being a smart ass here. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] FreeBSD Packages/Port for 7.3beta1...
Sean Chittenden writes:
> I've put together some packages for the 7.3beta1 release. The can be
> found here along with a tenative FreeBSD port:
>
>http://66.250.180.19/postgresql-7.3beta1/
I checked out this port and made some notes that you might find useful.
[Makefile]
You can remove --enable-locale, --enable-syslog, --with-CXX as configure
arguments. They no longer do anything.
This
LDFLAGS+= -L${LOCALBASE}/lib -lgnugetopt
CONFIGURE_ENV+= LDFLAGS="${LDFLAGS}"
is redundant. You already put LOCALBASE/lib into --with-libs. Also, if
you wish, we can automatically check for -lgnugetopt in configure. We
already do that for other spellings of the same library.
I would like some details on the following.
# if you want localized messages, make -DWITH_GETTEXT
# WARNING: this seems to require relinking binaries depending on
# libpq.so, including for example mod_php and tcl.
This
CONFIGURE_ENV+= "LIBS=-lintl"
LDFLAGS+= -L${LOCALBASE}/lib -lintl
is even more redundant, because configure checks for -lintl automatically
(and one of LIBS and LDFLAGS would have sufficed).
Multibyte is no longer an option (it's the default), so you can remove
anything that refers to it.
If you want to strip the binaries, you can use 'gmake install-strip'
instead of 'gmake install'. It's all automatic.
[patch-ak]
I assume you're going to fix this properly sometime...
[files/patch-al]
Can be removed for beta 2.
[files/dot.*.in]
Do you need the PATH assignment? Shouldn't the user decide for himself
what he wants in the path? PostgreSQL certainly doesn't need the path
set, if you're concerned about that.
PGLIB hasn't done anything for several releases...
PGDATESTYLE should now be set in the configuration file, so you can remove
the environment variable assignment.
Setting locales (LC_ALL) is now best done as an option to initdb. Be sure
to update pkg-message to that effect. Also, the encoding should be
specified to initdb (rather than configure --enable-multibyte=ENCODING).
Not sure what the TZ assignment is supposed to accomplish. It certainly
doesn't alter the way the regression tests turn out, as it seems to claim.
Might have been an ancient problem.
[files/patch.configure]
I think you should handle that through the makefiles. In fact, you
probably shouldn't specify an argument to the krb options if you're
concerned about this.
[files/post-install-notes]
Be sure to revise those, as some of the things are now shipped separately
(such as PgAccess).
[scripts/configure.postgresql]
Remove multibyte option.
PostgreSQL should work with Heimdal now.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TOAST docs
Alvaro Herrera writes: > Is there some documentation on TOAST? No. Why do you need any? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS]
Bruce Momjian writes: > Wow. That is clear. Why are we returning "year" as a double? Because we've been doing that for many years. > I would love to say that this is related to change in casts, but that > isn't the case. Sure it is. The float=>int casts need to be made implicit, or we'll have tons of problems like this. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] beta1 packaged
Giles Lean <[EMAIL PROTECTED]> writes: >> Rod Taylor <[EMAIL PROTECTED]> writes: >>> ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references >>> pktable(ptest1); >>> NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY >>> check(s) >>> + ERROR: Relation "pg_temp_5"."" does not exist >> >> That's pretty bizarre. Is it reproducible? Can you get in there with a >> debugger and try to figure out what's going wrong? > I saw a similar error on a NetBSD-1.5.1/i386 box, but have not been > able to reproduce it. Subsequent runs of 'gmake check' have all > passed. > Until I saw Rod's message I was thinking it was more evidence of > hardware flakiness with this particular machine, but perhaps not. > NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY check(s) > + ERROR: Relation "public"."^B^U&W<88>0}" does not exist I've applied the attached patch, which I think may cure these failures. regards, tom lane *** src/backend/commands/tablecmds.c.orig Wed Sep 4 17:30:18 2002 --- src/backend/commands/tablecmds.cThu Sep 12 17:06:58 2002 *** *** 2920,2926 * unfortunately). */ myRel = makeRangeVar(get_namespace_name(RelationGetNamespace(rel)), !RelationGetRelationName(rel)); /* * Preset objectAddress fields --- 2920,2926 * unfortunately). */ myRel = makeRangeVar(get_namespace_name(RelationGetNamespace(rel)), ! pstrdup(RelationGetRelationName(rel))); /* * Preset objectAddress fields ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Interesting results using new prepared statements
Barry Lind <[EMAIL PROTECTED]> writes: > ... I don't understand > why the timings for prepared statements would be less than for a regular > statement, and especially why using bind variables would be better than > without. I am concerned that prepared statements may be choosing a > different execution plan than non-prepared statements. That's entirely likely if you are using bind variables in the prepared statements, since the planner will not have access to the same constant values that it does in a plain SQL statement --- for example, "WHERE foo = $1" looks a lot different from "WHERE foo = 42" to the planner. In most cases I'd expect the planner to generate worse plans when given less info :-( ... but in your particular case it seems to be guessing slightly wrong. > But I am not > sure how to find out what the execution plan is for a prepared > statement, since EXPLAIN doesn't work for a prepared statement (i.e. > EXPLAIN EXECUTE , doesn't work). Hmmm --- I can see the usefulness of that, but it looks like a new feature and hence verboten during beta. Maybe a TODO for 7.4? regards, tom lane ---(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] Looking for more "big name" places that use PostgreSQL
Hi everyone, We're looking to get an initial "PostgreSQL Advocacy and Marketing" site up an running in the next day or so. Whilst we know of a reasonable number of large places running PostgreSQL (as shown on the http://techdocs.postgresql.org/techdocs/supportcontracts.php page), we're still looking for further examples. Specifically, we are looking for places that are happy to discuss it, either a) not publicly, or b) happy to let the world know about it. Probably about 1/3 to 1/4 of the large organisations that we know are using PostgreSQL for important work aren't yet able to announce it publicly. Please don't let this stop you from letting us know privately, as we are interested in the implementation details and will respect your confidentiality. So, if you're using PostgreSQL and haven't directly let us know, please do so now if you can. :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] failed Assert() in utf8_and_iso8859_1.c
Karel Zak <[EMAIL PROTECTED]> writes:
> In the server log file is:
> TRAP: FailedAssertion("!(len > 0)", File: "utf8_and_iso8859_1.c", Line: 45)
Hmm, looks like all the conversion_procs files have
Assert(len > 0);
Surely that should be Assert(len >= 0)?
I also notice that I neglected to change PG_RETURN_INT32(0) to
PG_RETURN_VOID() in these files. That's only cosmetic, but
probably it should be done.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.3beta and ecpg
Michael Meskes <[EMAIL PROTECTED]> writes: > On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote: >> But you must implement your own PREPARE/EXECUTE anyway, using ecpg >> variables, no? > In ecpg you can use a string variable or constant holding the statement > to prepare that statement as in > exec sql prepare STMT from string; Sure --- and that is exactly *not* what the backend facility does. In the backend PREPARE you supply the statement to be prepared directly in the same SQL command, not as the value of some variable. > Now if you have a parameter in the prepared statement by just specify > "?" instead some value, you add a using clause during execution to set > the values. And a plain "?" isn't going to fly as the parameter marker, either. The backend wants to know what datatype each parameter is supposed to be. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PGXLOG variable worthwhile?
Curt Sampson <[EMAIL PROTECTED]> writes: > On Thu, 12 Sep 2002, Justin Clift wrote: >> Am just wondering if we've ever considered adding a PGXLOG environment >> variable that would point to the pg_xlog directory? > IMHO, a much better way to support this is to put this information into > the config file. That way it can't easily change when you happen to, say, > start postgres in the wrong window. Yes. We rejected environment-variable-based xlog location for reasons that apply equally well to Windows. The xlog location *must* be stored in a physical file in the data directory; anything else is too unsafe. The current technology for that is a symlink. While it doesn't have to be a symlink as opposed to some sort of config file, I don't have the slightest problem with saying that we don't support relocation of xlog on older Windoid platforms. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS]
Bruce Momjian <[EMAIL PROTECTED]> writes: > I would love to say that this is related to change in casts, but that > isn't the case. It is the new double-precision handling of dates; You've got that exactly backwards: date_part has always returned double. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] fixpoint
Hi, Does anyone know any implementation of a fixpoint operator (recursive queries) for postgreSQL? Thanks, Luciano. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
Oliver Elphick <[EMAIL PROTECTED]> writes: > On Thu, 2002-09-12 at 15:54, Tom Lane wrote: >> Only if people dump their old databases with 7.3 pg_dump; which is an >> assumption I'd rather not make if we can avoid it. > I don't understand. > The only pg_dump we can fix is 7.3. Certainly. But if we hack the backend so it still accepts OPAQUE, then we can still load 7.2 dump files. > If someone restores into 7.3 with a 7.2 dump they are going to have > other problems, such as turning all their functions private. True, but they can fix that after-the-fact. Not sure if there is any good workaround for the PL-handler problem in a 7.2 pg_dumpall script. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
Philip Warner <[EMAIL PROTECTED]> writes: > At 10:31 AM 12/09/2002 -0400, Tom Lane wrote: >> Does anyone see a cleaner answer than re-allowing OPAQUE for PL >> handlers? > What about extending the function manager macros to know about return types > (at least for builtin types)? Er ... what has that got to do with this? And what sort of extension do you think we need? We already have the RETURN_foo() macros. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PGXLOG variable worthwhile?
I wrote: > scott.marlowe wrote: >> >> I wouldn't assume that. It's been years since I tested it, but back >> then, the command line and all program I used could see the link >> created by ln that came with the resource kit. They were distinctly >> different from the shortcut type of links, in that they seems >> transparent like short cuts in unix generally are. >> >> Do you have the resource kit or the gnu utils from it? > > > The situation appears to be this: > > 1. Soft links are available on NTFS 5 (2K/XP) as Reparse Points via the > DeviceIoControl() function for any application using the standard C > library routines. > > 2. Soft links are available on any filesystem under 95/98/ME/NT4/2K/XP > as OLE streams (.lnk files) for Shell-aware applications. > > 3. Hard links are available on NTFS 5 (2K/XP) via the CreateHardLink() API. > 4. Hard links are available on NTFS (NT3.1/NT4) via the BackupWrite() > API by writing a special stream to the NTFS. I also believe (I could be wrong) that for directories, the only two methods of links are the Soft link methods above. So PGXLOG cannot use soft links on a non-XP/2K machine unless it is "Shell-Aware". For example, in a cygwin bash command window: mkdir dir1 ln dir1 dir2 <- Error using Cygwin implementation ln -s dir1 dir2 <- Creates a Shell short-cut (NT4) echo "Hello" > dir1/test.txt cat dir2/test.txt "Hello" <- Cygwin's cat(bash?) is shell short-cut aware Now, in a Windows NT command prompt: notepad dir2\test.txt <- Notepad can't find file notepad dir2.lnk <- Displays link contents That means for a native port with a different PGXLOG directory running on NT4, the only choice *using links* is to make the native port shell short-cut aware. I could be wrong but I don't think so. Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
Oliver Elphick wrote: On Thu, 2002-09-12 at 15:54, Tom Lane wrote: Oliver Elphick <[EMAIL PROTECTED]> writes: On Thu, 2002-09-12 at 15:31, Tom Lane wrote: Does anyone see a cleaner answer than re-allowing OPAQUE for PL handlers? Can't you just special case the language handlers when dumping <7.3 and change 'RETURNS opaque' to 'RETURNS language_handler'? That's all that is needed to let them be restored OK into 7.3. Only if people dump their old databases with 7.3 pg_dump; which is an assumption I'd rather not make if we can avoid it. I don't understand. The only pg_dump we can fix is 7.3. You can't backport such a change into 7.2 or it won't work for 7.2 restore. If you are using 7.3 pg_dump it isn't an assumption but a certainty that it is being used. If someone restores into 7.3 with a 7.2 dump they are going to have other problems, such as turning all their functions private. Since they are going to need to edit the dump anyway, they might as well edit this bit too. Surely we should be advising them to use 7.3's pg_dump to do the upgrade. The alternative approach is to build a set of kludges into >=7.3 to change opague to language_handler when a language function is installed. That doesn't sound like a good idea. Is it possible to build a standalone 7.3 dump/dump_all program that can be run on a server with an existing 7.2.x installation and not be linked against 7.3 libraries? Call it a migration agent if you will. A notice of somekind would help: Before upgrading, dump the database using this program.
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
On Thu, 12 Sep 2002, scott.marlowe wrote: > Agreed. > > Actually, an argument could likely be made that changes that require > initdb should be done as early as possible since the later the change the > more people there will be to test the change, and there will be fewer > people who actually have to initdb since a lot of folks don't test beta > releases until the 3rd or 4th beta. My mental dyslexia strikes again, that should be: ... since the EARLIER the change the more people there will be to test the change, ... sheesh. Sorry... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
On Thu, 2002-09-12 at 15:54, Tom Lane wrote: > Oliver Elphick <[EMAIL PROTECTED]> writes: > > On Thu, 2002-09-12 at 15:31, Tom Lane wrote: > >> Does anyone see a cleaner answer than re-allowing OPAQUE for PL > >> handlers? > > > Can't you just special case the language handlers when dumping <7.3 and > > change 'RETURNS opaque' to 'RETURNS language_handler'? That's all that > > is needed to let them be restored OK into 7.3. > > Only if people dump their old databases with 7.3 pg_dump; which is an > assumption I'd rather not make if we can avoid it. I don't understand. The only pg_dump we can fix is 7.3. You can't backport such a change into 7.2 or it won't work for 7.2 restore. If you are using 7.3 pg_dump it isn't an assumption but a certainty that it is being used. If someone restores into 7.3 with a 7.2 dump they are going to have other problems, such as turning all their functions private. Since they are going to need to edit the dump anyway, they might as well edit this bit too. Surely we should be advising them to use 7.3's pg_dump to do the upgrade. The alternative approach is to build a set of kludges into >=7.3 to change opague to language_handler when a language function is installed. That doesn't sound like a good idea. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Let the wicked forsake his way, and the unrighteous man his thoughts; and let him return unto the LORD, and He will have mercy upon him; and to our God, for he will abundantly pardon." Isaiah 55:7 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PGXLOG variable worthwhile?
scott.marlowe wrote: > On Fri, 13 Sep 2002, Justin Clift wrote: > >>Would it be correct to say that the 'ln' command in the MS Resource Kit >>creates this kind of shortcut too, as the Reparse Points feature doesn't >>seem to be possible under NT4? > > > I wouldn't assume that. It's been years since I tested it, but back then, > the command line and all program I used could see the link created by ln > that came with the resource kit. They were distinctly different from the > shortcut type of links, in that they seems transparent like short cuts in > unix generally are. > > Do you have the resource kit or the gnu utils from it? The situation appears to be this: 1. Soft links are available on NTFS 5 (2K/XP) as Reparse Points via the DeviceIoControl() function for any application using the standard C library routines. 2. Soft links are available on any filesystem under 95/98/ME/NT4/2K/XP as OLE streams (.lnk files) for Shell-aware applications. 3. Hard links are available on NTFS 5 (2K/XP) via the CreateHardLink() API. See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createhardlink.asp 4. Hard links are available on NTFS (NT3.1/NT4) via the BackupWrite() API by writing a special stream to the NTFS. Example: http://www.mvps.org/win32/ntfs/lnw.cpp The cygwin implementation of link(): http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?rev=1.149.2.23&content-type=text/x-cvsweb-markup&cvsroot=src 1. Will use CreateHardLink() if on 2K/XP 2. Will try to use the BackupWrite() method 3. Failing #2 will just copy the file See how fun Microsoft makes things? Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
On Thu, 12 Sep 2002, Matthew T. OConnor wrote: > > > The count approach seems definitely the right way, but a check (possibly > > > a slow one) can be probably done without initdb. > > > > We can certainly do the proper fix in 7.4; do we consider this bug > > important enough to do an initdb for 7.3beta2? I don't have a strong > > feeling either way about that. > > I think we are too scared of doing initdb during beta... > > Initdb during beta should not be evaultated on a per bug basis, but keep a > list of all things that could be fixed and judge if the total of all the > fixes is worth one initdb. Right now off the top of my head I can think of > the split function and this inherited change, are there more? > > my two cents... Agreed. Actually, an argument could likely be made that changes that require initdb should be done as early as possible since the later the change the more people there will be to test the change, and there will be fewer people who actually have to initdb since a lot of folks don't test beta releases until the 3rd or 4th beta. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PGXLOG variable worthwhile?
On Thu, 12 Sep 2002, Justin Clift wrote: > Am just wondering if we've ever considered adding a PGXLOG environment > variable that would point to the pg_xlog directory? IMHO, a much better way to support this is to put this information into the config file. That way it can't easily change when you happen to, say, start postgres in the wrong window. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS]
Dave Page wrote:
> Oliver reported:
>
> 2. The dump produced:
> CREATE TABLE cust_alloc_history (
> ...
> "year" integer DEFAULT date_part('year'::text,
> ('now'::text)::timestamp(6) with time zone) NOT NULL,
> ...
> ERROR: Column "year" is of type integer but default expression is
> of type double precision
> You will need to rewrite or cast the expression
>
> For an original definition of:
>
> year INTEGER DEFAULT
> date_part('year',CURRENT_TIMESTAMP)
Wow. That is clear. Why are we returning "year" as a double? Yes, I
see now:
test=> \df date_part
List of functions
Result data type | Schema | Name|Argument data types
--++---+---
double precision | pg_catalog | date_part | text, abstime
double precision | pg_catalog | date_part | text, date
double precision | pg_catalog | date_part | text, interval
double precision | pg_catalog | date_part | text, reltime
double precision | pg_catalog | date_part | text, time with time zone
double precision | pg_catalog | date_part | text, time without time zone
double precision | pg_catalog | date_part | text, timestamp with time zone
double precision | pg_catalog | date_part | text, timestamp without time zone
I would love to say that this is related to change in casts, but that
isn't the case. It is the new double-precision handling of dates; and
I see no easy way to fix this, and you can't fix this after the data
load because the table wasn't created. Yuck.
I have to ask, why are we using a double here rather than a 64-bit
value, if available?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
> > The count approach seems definitely the right way, but a check (possibly > > a slow one) can be probably done without initdb. > > We can certainly do the proper fix in 7.4; do we consider this bug > important enough to do an initdb for 7.3beta2? I don't have a strong > feeling either way about that. I think we are too scared of doing initdb during beta... Initdb during beta should not be evaultated on a per bug basis, but keep a list of all things that could be fixed and judge if the total of all the fixes is worth one initdb. Right now off the top of my head I can think of the split function and this inherited change, are there more? my two cents... ---(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] PGXLOG variable worthwhile?
On Fri, 13 Sep 2002, Justin Clift wrote: > "scott.marlowe" wrote: > > > > Seems like the NT4 users are left out in the cold though until we add > > > some kind of ability for PostgreSQL to not look at the filesystem for > > > info about where to put the xlog files. > > > > This isn't true. With the resource kit, you get the gnu utils, and ln > > works a charm under NT4 with ntfs. And not just for directories, but > > files as well. Unless Microsoft somehow removed that functionality in the > > intervening years since I've used NT. (wouldn't put it past them, but I > > doubt they have.) > > The reference point that I'm working from is this: > > - Am testing out the third beta of the Native PostgreSQL port for > Windows, on NT4 SP6 at present. > - Have an internal RAID array of Seagate Cheetah 10kRPM drives. When > installing the PGDATA directory on one drive it gives a certain kind of > performance, and I'm interested in testing the performance of the Native > PostgreSQL port for Windows with the xlog directory being located on > another drive. > - Have tried doing normal shortcuts, and have also tried using the > cygwin "ln" command to create the appropriate soft link. Both > approaches create a shortcut object of the correct name pointing to the > correct place on the new drive, but the only thing that appears to > follow this shortcut is when I click on them using Windows Explorer. > The Native PostgreSQL port for Windows doesn't, and neither do a few > other applications I tested. > > Would it be correct to say that the 'ln' command in the MS Resource Kit > creates this kind of shortcut too, as the Reparse Points feature doesn't > seem to be possible under NT4? I wouldn't assume that. It's been years since I tested it, but back then, the command line and all program I used could see the link created by ln that came with the resource kit. They were distinctly different from the shortcut type of links, in that they seems transparent like short cuts in unix generally are. Do you have the resource kit or the gnu utils from it? Looking at this url: http://unxutils.sourceforge.net/ the part for ln.exe says it makes real hard links on ntfs (which means they would be on the same drive.) So I'm not sure if ntfs supports soft links across volumes transparently or not now. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PGXLOG variable worthwhile?
scott.marlowe wrote: > > Seems like the NT4 users are left out in the cold though until we add > > some kind of ability for PostgreSQL to not look at the filesystem for > > info about where to put the xlog files. > > This isn't true. With the resource kit, you get the gnu utils, and ln > works a charm under NT4 with ntfs. And not just for directories, but > files as well. Unless Microsoft somehow removed that functionality in the > intervening years since I've used NT. (wouldn't put it past them, but I > doubt they have.) Yes, this is what I remember, that Cygwin had symlinks, and at that time that was the only Win32 OS we supported. Now, with native Win32 port coming, we have to figure out what is available. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PGXLOG variable worthwhile?
"scott.marlowe" wrote: > > Seems like the NT4 users are left out in the cold though until we add > > some kind of ability for PostgreSQL to not look at the filesystem for > > info about where to put the xlog files. > > This isn't true. With the resource kit, you get the gnu utils, and ln > works a charm under NT4 with ntfs. And not just for directories, but > files as well. Unless Microsoft somehow removed that functionality in the > intervening years since I've used NT. (wouldn't put it past them, but I > doubt they have.) The reference point that I'm working from is this: - Am testing out the third beta of the Native PostgreSQL port for Windows, on NT4 SP6 at present. - Have an internal RAID array of Seagate Cheetah 10kRPM drives. When installing the PGDATA directory on one drive it gives a certain kind of performance, and I'm interested in testing the performance of the Native PostgreSQL port for Windows with the xlog directory being located on another drive. - Have tried doing normal shortcuts, and have also tried using the cygwin "ln" command to create the appropriate soft link. Both approaches create a shortcut object of the correct name pointing to the correct place on the new drive, but the only thing that appears to follow this shortcut is when I click on them using Windows Explorer. The Native PostgreSQL port for Windows doesn't, and neither do a few other applications I tested. Would it be correct to say that the 'ln' command in the MS Resource Kit creates this kind of shortcut too, as the Reparse Points feature doesn't seem to be possible under NT4? Can only think of two real solutions at present, one being for us to add a PGXLOG environment variable or similar ability (GUC parameter perhaps?), and the other would be for the Native PostgreSQL for Windows port to follow these shortcuts. Not if any of these is all that easy, or maybe there is another solution that would work (apart from ignoring the problem). :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] failed Assert() in utf8_and_iso8859_1.c
Hi,
I have file with this code:
--
\l
SHOW SERVER_ENCODING;
SHOW CLIENT_ENCODING;
--- Languages table
---
CREATE TABLE lang
(
--- 'id' is here lang abbreviation
---
id varchar(3) PRIMARY KEY,
namevarchar(16) NOT NULL--- lang fullname
);
COPY lang FROM stdin;
EN English
DE German
JP Japanese
\.
--
and now I use latest PostgreSQL from CVS:
$ psql anydb < langs.sql
List of databases
Name| Owner | Encoding
---+--+---
anydb | zakkr| UNICODE
template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
test | postgres | SQL_ASCII
(4 rows)
server_encoding
-
UNICODE
(1 row)
client_encoding
-
LATIN1
(1 row)
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'lang_pkey' for table
'lang'
CREATE TABLE
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
lost synchronization with server, resetting connection
connection to server was lost
In the server log file is:
TRAP: FailedAssertion("!(len > 0)", File: "utf8_and_iso8859_1.c", Line: 45)
If I use INSERT instead COPY it's OK.
Karel
--
Karel Zak <[EMAIL PROTECTED]>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Schemas not available for pl/pgsql %TYPE....
Does anyone know if such effort is also required to pl/python to become "schema aware"? Regards, Greg Copeland On Wed, 2002-09-11 at 19:24, Bruce Momjian wrote: > > Patch applied. Thanks. > > --- > > > Joe Conway wrote: > > Tom Lane wrote: > > > Sean Chittenden <[EMAIL PROTECTED]> writes: > > > > > >>::sigh:: Is it me or does it look like all > > >>of pl/pgsql is schema un-aware (ie, all of the declarations). -sc > > > > > > > > > Yeah. The group of routines parse_word, parse_dblword, etc that are > > > called by the lexer certainly all need work. There are some > > > definitional issues to think about, too --- plpgsql presently relies on > > > the number of names to give it some idea of what to look for, and those > > > rules are probably all toast now. Please come up with a sketch of what > > > you think the behavior should be before you start hacking code. > > > > Attached is a diff -c format proposal to fix this. I've also attached a short > > test script. Seems to work OK and passes all regression tests. > > > > Here's a breakdown of how I understand plpgsql's "Special word rules" -- I > > think it illustrates the behavior reasonably well. New functions added by this > > patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype: > > > > > > Identifiers (represents)parsing function > > > > identifierplpgsql_parse_word > > tg_argv > > T_LABEL (label) > > T_VARIABLE (variable) > > T_RECORD(record) > > T_ROW (row) > > > > identifier.identifier plpgsql_parse_dblword > > T_LABEL > > T_VARIABLE (label.variable) > > T_RECORD(label.record) > > T_ROW (label.row) > > T_RECORD > > T_VARIABLE (record.variable) > > T_ROW > > T_VARIABLE (row.variable) > > > > identifier.identifier.identifier plpgsql_parse_tripword > > T_LABEL > > T_RECORD > > T_VARIABLE (label.record.variable) > > T_ROW > > T_VARIABLE (label.row.variable) > > > > identifier%TYPE plpgsql_parse_wordtype > > T_VARIABLE > > T_DTYPE (variable%TYPE) > > T_DTYPE (typname%TYPE) > > > > identifier.identifier%TYPE plpgsql_parse_dblwordtype > > T_LABEL > > T_VARIABLE > > T_DTYPE (label.variable%TYPE) > > T_DTYPE (relname.attname%TYPE) > > > > > > identifier.identifier.identifier%TYPE plpgsql_parse_tripwordtype > > T_DTYPE (nspname.relname.attname%TYPE) > > > > identifier%ROWTYPE plpgsql_parse_wordrowtype > > T_DTYPE (relname%ROWTYPE) > > > > > > identifier.identifier%ROWTYPE plpgsql_parse_dblwordrowtype > > T_DTYPE (nspname.relname%ROWTYPE) > > > > > > Parameters - parallels the above > > > > $#plpgsql_parse_word > > $#.identifier plpgsql_parse_dblword > > $#.identifier.identifier plpgsql_parse_tripword > > $#%TYPE plpgsql_parse_wordtype > > $#.identifier%TYPE plpgsql_parse_dblwordtype > > $#.identifier.identifier%TYPE plpgsql_parse_tripwordtype > > $#%ROWTYPE plpgsql_parse_wordrowtype > > $#.identifier%ROWTYPE plpgsql_parse_dblwordrowtype > > > > Comments? > > > > Thanks, > > > > Joe > > > Index: src/pl/plpgsql/src/pl_comp.c > > === > > RCS file: /opt/src/cvs/pgsql-server/src/pl/plpgsql/src/pl_comp.c,v > > retrieving revision 1.51 > > diff -c -r1.51 pl_comp.
Re: [HACKERS] PGXLOG variable worthwhile?
On Thu, 12 Sep 2002, Justin Clift wrote: > Mike Mascari wrote: > > > In Windows 2000 and Windows XP with an NTFS filesystem, > > Microsoft has added Reparse Points, which allow for the > > implementation of symbolic links for directories. Microsoft > > calls them "Junctions". I *believe* the function used for > > creating reparse points is DeviceIoControl() with the > > FSCTL_SET_REPARSE_POINT I/O control code. I don't have quick > > access to 2K or XP, but it is clearly not supported by Win32 on > > 95/98/ME. > > > > Here's a link discussing the features of NTFS5 and Reparse Points: > > > > >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag00/html/NTFSPart1.asp > > That's really useful info. Reparse points under Win2k (mount points to > the rest of us) are definitely something to try out in the future then. > :) > > Seems like the NT4 users are left out in the cold though until we add > some kind of ability for PostgreSQL to not look at the filesystem for > info about where to put the xlog files. This isn't true. With the resource kit, you get the gnu utils, and ln works a charm under NT4 with ntfs. And not just for directories, but files as well. Unless Microsoft somehow removed that functionality in the intervening years since I've used NT. (wouldn't put it past them, but I doubt they have.) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
At 10:31 AM 12/09/2002 -0400, Tom Lane wrote: >Does anyone see a cleaner answer than re-allowing OPAQUE for PL >handlers? What about extending the function manager macros to know about return types (at least for builtin types)? 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3beta and ecpg
On Thu, Sep 12, 2002 at 09:07:20AM -0400, Tom Lane wrote: > Michael Meskes <[EMAIL PROTECTED]> writes: > > I'm awfully sorry that I missed this thread. But I do not really > > understand the problem. If we cannot be exactly as specified why aren't > > we coming close? As it stands now I have to implement my own > > PREPARE/EXECUTE in ecpg and the syntax does clash with the backend one. > > But you must implement your own PREPARE/EXECUTE anyway, using ecpg > variables, no? If you can really embed what you need in the backend > facility, and only the syntax variation is getting in the way, then > maybe I misunderstand the problem. How do parameters of PREPAREd > statements work in ecpg? In ecpg you can use a string variable or constant holding the statement to prepare that statement as in exec sql prepare STMT from string; This binds the ident STMT to the statement in string. Later you can then declare a cursor using exec sql declare CURS cursor for STMT; or execute the statement using exec sql execute STMT; Now if you have a parameter in the prepared statement by just specify "?" instead some value, you add a using clause during execution to set the values. I'm not sure where you expect the ecpg variables. If you're talking about C variables they won't be seen by any statement since ecpg creates an ascii string of the whole statement before sending it to the backend. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
Oliver Elphick <[EMAIL PROTECTED]> writes: > On Thu, 2002-09-12 at 15:31, Tom Lane wrote: >> Does anyone see a cleaner answer than re-allowing OPAQUE for PL >> handlers? > Can't you just special case the language handlers when dumping <7.3 and > change 'RETURNS opaque' to 'RETURNS language_handler'? That's all that > is needed to let them be restored OK into 7.3. Only if people dump their old databases with 7.3 pg_dump; which is an assumption I'd rather not make if we can avoid it. OTOH, if we did do such a thing we could probably fix OPAQUE triggers and datatype I/O ops too ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
On Thu, 2002-09-12 at 15:31, Tom Lane wrote: > Does anyone see a cleaner answer than re-allowing OPAQUE for PL > handlers? Can't you just special case the language handlers when dumping <7.3 and change 'RETURNS opaque' to 'RETURNS language_handler'? That's all that is needed to let them be restored OK into 7.3. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Let the wicked forsake his way, and the unrighteous man his thoughts; and let him return unto the LORD, and He will have mercy upon him; and to our God, for he will abundantly pardon." Isaiah 55:7 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
Hannu Krosing <[EMAIL PROTECTED]> writes: >> Hm. Seems like attisinherited should have been a count, not a boolean. >> Is anyone sufficiently excited about this issue to force an initdb to >> fix it? > The count approach seems definitely the right way, but a check (possibly > a slow one) can be probably done without initdb. Slow, complicated to code, and deadlock-prone (since you'd have to acquire locks on the other parent tables). My feeling is we fix this with a counted attisinherited field, or don't fix at all. We can certainly do the proper fix in 7.4; do we consider this bug important enough to do an initdb for 7.3beta2? I don't have a strong feeling either way about that. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
Tom Lane dijo: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > I've come upon a misbehaviour of drop column, where drop column > > unconditionally drops inherited column from child tables. > > What it should do is to check if the same column is not inherited from > > other parents and drop it only when it is not > > Hm. Seems like attisinherited should have been a count, not a boolean. I'll try to make a fix and submit. > Is anyone sufficiently excited about this issue to force an initdb to > fix it? If people thinks it's important, the fix can be integrated. If not, it can wait until 7.4. -- Alvaro Herrera () "Aprende a avergonzarte mas ante ti que ante los demas" (Democrito) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OPAQUE and 7.2-7.3 upgrade
Bruce Momjian <[EMAIL PROTECTED]> writes: > Well, our whole goal was to get rid of the opaque thing entirely so I am > not sure if we want to keep that going. In fact, I am not sure it is > even possible to remap opaque because it now is represented by so many > other values. We do still allow OPAQUE for triggers and datatype I/O functions, though I would like to take that out by and by. The only case where OPAQUE is rejected now but was allowed before is PL language handlers. We could weaken that --- but since there are no user-defined PL handlers in the wild (AFAIK anyway), I'd prefer not to. My original thought about this was that people should run 7.3's createlang script to load proper 7.3 language definitions into their 7.3 database. (This would not only fix the OPAQUE business but also replace any remaining absolute paths for language handlers with the $libdir form, which is an important 7.2 change that doesn't seem to have propagated very well because people are just doing dumps and reloads.) But I now see that this answer doesn't work for pg_dumpall scripts. Does anyone see a cleaner answer than re-allowing OPAQUE for PL handlers? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
On Thu, 2002-09-12 at 16:14, Tom Lane wrote: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > I've come upon a misbehaviour of drop column, where drop column > > unconditionally drops inherited column from child tables. > > What it should do is to check if the same column is not inherited from > > other parents and drop it only when it is not > > Hm. Seems like attisinherited should have been a count, not a boolean. either that, or some check at drop column time. > Is anyone sufficiently excited about this issue to force an initdb to > fix it? The count approach seems definitely the right way, but a check (possibly a slow one) can be probably done without initdb. The other sad thing about the current behaviour is that in addition to being wrong it also breaks dump/reload - after dump/reload the initially dropped column is back in c1. - Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance
Hannu Krosing <[EMAIL PROTECTED]> writes: > I've come upon a misbehaviour of drop column, where drop column > unconditionally drops inherited column from child tables. > What it should do is to check if the same column is not inherited from > other parents and drop it only when it is not Hm. Seems like attisinherited should have been a count, not a boolean. Is anyone sufficiently excited about this issue to force an initdb to fix it? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3beta and ecpg
Michael Meskes <[EMAIL PROTECTED]> writes: > I'm awfully sorry that I missed this thread. But I do not really > understand the problem. If we cannot be exactly as specified why aren't > we coming close? As it stands now I have to implement my own > PREPARE/EXECUTE in ecpg and the syntax does clash with the backend one. But you must implement your own PREPARE/EXECUTE anyway, using ecpg variables, no? If you can really embed what you need in the backend facility, and only the syntax variation is getting in the way, then maybe I misunderstand the problem. How do parameters of PREPAREd statements work in ecpg? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PGXLOG variable worthwhile?
Mike Mascari wrote: > In Windows 2000 and Windows XP with an NTFS filesystem, > Microsoft has added Reparse Points, which allow for the > implementation of symbolic links for directories. Microsoft > calls them "Junctions". I *believe* the function used for > creating reparse points is DeviceIoControl() with the > FSCTL_SET_REPARSE_POINT I/O control code. I don't have quick > access to 2K or XP, but it is clearly not supported by Win32 on > 95/98/ME. > > Here's a link discussing the features of NTFS5 and Reparse Points: > > >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag00/html/NTFSPart1.asp That's really useful info. Reparse points under Win2k (mount points to the rest of us) are definitely something to try out in the future then. :) Seems like the NT4 users are left out in the cold though until we add some kind of ability for PostgreSQL to not look at the filesystem for info about where to put the xlog files. Regards and best wishes, Justin Clift > Mike Mascari > [EMAIL PROTECTED] -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_dump problems in upgrading
On Thu, 2002-09-12 at 00:52, Philip Warner wrote: > At 12:31 PM 9/09/2002 +0100, Oliver Elphick wrote: > >3. A view is being created before one of the tables it refers to. > >Should not views be created only at the very end? > > This would be trivial (and we already put several items at the end), but I > am not sure it would fix the problem since views can also be on other > views. I presume the bad ordering happened as a result of a drop/create on > a table? Or is there some other cause? It could be, but I don't know for sure. This is a development db which quite often gets reloaded entirely and repopulated. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Let the wicked forsake his way, and the unrighteous man his thoughts; and let him return unto the LORD, and He will have mercy upon him; and to our God, for he will abundantly pardon." Isaiah 55:7 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PGXLOG variable worthwhile?
Dave Page wrote: > >>-Original Message- >>From: Bruce Momjian [mailto:[EMAIL PROTECTED]] >> >>Also, I have heard symlinks are available in native Windows >>but the interface to them isn't clearly visible. Can someone >>clarify that? > > > Well there are 'shortcuts' but I wouldn't want to trust my xlog > directory to one. These are Shell OLE links. As Dave points out, it requires the shell to interpret the shortcut. > > Even if I did, iirc, unless you are using the shell api, they just > appear to be regular files anyway (for example, in Cygwin vi, I can edit > a shortcut to a directory). > > Regards, Dave. In Windows 2000 and Windows XP with an NTFS filesystem, Microsoft has added Reparse Points, which allow for the implementation of symbolic links for directories. Microsoft calls them "Junctions". I *believe* the function used for creating reparse points is DeviceIoControl() with the FSCTL_SET_REPARSE_POINT I/O control code. I don't have quick access to 2K or XP, but it is clearly not supported by Win32 on 95/98/ME. Here's a link discussing the features of NTFS5 and Reparse Points: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag00/html/NTFSPart1.asp Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3beta and ecpg
On Wed, Sep 11, 2002 at 04:36:31PM -0400, Tom Lane wrote: > IIRC, the conclusion of our earlier debate about backend PREPARE/EXECUTE > syntax was that since it was not implementing exactly the behavior > specified for embedded SQL (and couldn't, not being an embedded > operation) it would be better to deliberately avoid using exactly the > same syntax. See thread starting at > http://archives.postgresql.org/pgsql-hackers/2002-07/msg00814.php I'm awfully sorry that I missed this thread. But I do not really understand the problem. If we cannot be exactly as specified why aren't we coming close? As it stands now I have to implement my own PREPARE/EXECUTE in ecpg and the syntax does clash with the backend one. This would force me to not allow the backend's prepare/execute at all in embedded sql but use the work around we've been using ever since. But the backend implementation certainly is better and faster, so I'd love to switch. > We can revisit that decision if you like, but you must convince us that > it was wrong, not just say "of course we should change it". Again, please take my apologies, since I missed the discussion. I'm so swarmed with work and emails that I have to delete some by just looking at the subject and appearantly I didn't see the relevance of this one. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PGXLOG variable worthwhile?
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED]] > Sent: 12 September 2002 06:27 > To: Justin Clift > Cc: PostgreSQL Hackers Mailing List > Subject: Re: [HACKERS] PGXLOG variable worthwhile? > > Also, I have heard symlinks are available in native Windows > but the interface to them isn't clearly visible. Can someone > clarify that? Well there are 'shortcuts' but I wouldn't want to trust my xlog directory to one. Even if I did, iirc, unless you are using the shell api, they just appear to be regular files anyway (for example, in Cygwin vi, I can edit a shortcut to a directory). Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
