[HACKERS] DROP COLUMN misbehaviour with multiple inheritance
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 Here is the test case: hannu=# create table p1(id int, name text); CREATE TABLE hannu=# create table p2(id2 int, name text); CREATE TABLE hannu=# create table c1(age int) inherits(p1,p2); NOTICE: CREATE TABLE: merging multiple inherited definitions of attribute name CREATE TABLE hannu=# \d c1 Table public.c1 Column | Type | Modifiers +-+--- id | integer | name | text| id2| integer | age| integer | hannu=# alter table p1 drop column name; ALTER TABLE hannu=# \d c1 Table public.c1 Column | Type | Modifiers +-+--- id | integer | id2| integer | age| integer | The column c1.name should survive the drop from p1, as it is also inherited from p2. Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS]
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: 12 September 2002 00:53
To: Dave Page
Cc: Oliver Elphick; [EMAIL PROTECTED]
Subject: Re: [HACKERS]
OK, I am going to add these items to the open items list
because I am having trouble keeping track of all the
compatibility changes for pg_dump.
I have:
Loading 7.2 pg_dumps
opaque language handler no longer recognized
What else is there?
Do cast problems related to pg_dump loading or to working
with the data after the load? Is it casts in user functions?
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)
Regards, Dave.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
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])
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] 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?
Mike Mascari wrote: snip 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] 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] 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] 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] 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
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
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 (alvherre[a]atentus.com) 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] 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] 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] 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
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] PGXLOG variable worthwhile?
On Thu, 12 Sep 2002, Justin Clift wrote: Mike Mascari wrote: snip 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] 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) new identifier.identifier.identifier%TYPE plpgsql_parse_tripwordtype T_DTYPE (nspname.relname.attname%TYPE) identifier%ROWTYPE plpgsql_parse_wordrowtype T_DTYPE (relname%ROWTYPE) new 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.c *** src/pl/plpgsql/src/pl_comp.c4 Sep 2002 20:31:47 - 1.51 --- src/pl/plpgsql/src/pl_comp.c9 Sep 2002 04:22:24 - *** *** 1092,1097 --- 1092,1217
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] 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.23content-type=text/x-cvsweb-markupcvsroot=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] 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] 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. snip 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
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] 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]
[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]
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] 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] 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 preparedStatementName, 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
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^UW88F00} 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]
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] 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] 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] 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] 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 (alvherre[a]atentus.com) 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] 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
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
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]
[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 (alvherre[a]atentus.com) 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 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
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
[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=libml=2a1=1002+Mumps+Language+Researcha2=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]
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]
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 (alvherre[a]atentus.com) 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. 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]
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 (alvherre[a]atentus.com) 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] 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])
[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] 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
