[HACKERS] Bug in user-defined types?
Hi, In response to comments made here, I have been rewriting the unsigned types as externally loadable. Using the same routines that worked fine when linked statically into the backend gives me core-dumps only. Creating only a single uint2 type with I/O routines, I get test=# create table u2 ( u uint2); CREATE test=# insert into u2 values (12::uint2); pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. Running this under gdb (I tried this on alpha as well) backend insert into u2 values (12::uint2); (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x40115573 in memcpy () from /lib/libc.so.6 (gdb) where #0 0x40115573 in memcpy () from /lib/libc.so.6 #1 0x80cfb92 in _copyConst () #2 0x80d25d9 in copyObject () #3 0x80ebad9 in expression_tree_mutator () #4 0x80eb407 in eval_const_expressions_mutator () #5 0x80ebe42 in expression_tree_mutator () #6 0x80eb407 in eval_const_expressions_mutator () #7 0x80ebdf2 in expression_tree_mutator () #8 0x80eb407 in eval_const_expressions_mutator () #9 0x80eaf87 in eval_const_expressions () #10 0x80e6d2a in preprocess_expression () #11 0x80e6751 in subquery_planner () #12 0x80e66c0 in planner () #13 0x81036e7 in pg_plan_query () #14 0x81038d9 in pg_exec_query_string () #15 0x81049d4 in PostgresMain () #16 0x80ce884 in main () #17 0x400d8a42 in __libc_start_main () from /lib/libc.so.6 (gdb) It never seems to get to my code. So either I've defined something incorrectly or there is a bug. I'd appreciate it if somebody more knowledgable than I could have a look at it. I've included a tar with the definitions. BTW it may be good to update the complex example to the new C-calling interface, as there is no example of creating a type with the new calling interface. Cheers, Adriaan utest.tar.gz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: plpython for postgres 7.1
On Sat, Mar 31, 2001 at 11:45:13PM -0500, Andrew Bosma wrote: Hello all A couple of weeks ago I received an email from Albert Langer inquiring about the status of the python language module I had written for postgresql. I told him I could have the port to postgresql 7.1 done by the middle of this week (march 25-31). Well, it's the end of this week, but I've finished it. Besides the conversion to the new style function manager, I've implemented a complete SPI interface. (The 7.0 module couldn't execute saved plans.) If you are interested in experimenting with the module it is available at "http://users.ids.net/~bosma" download the link "tarball for postgresql 7.1" comments, bug reports and suggestions are appreciated. Sure :-) It's great news that anyone works on PL/Python. Why you not say something about it in hackers list? (I ask about this several time!). I hope we will see it in 7.2 and will be possible sending paches. I see the code and it's probably not bad, but needs some changes (remove malloc(), ..etc :-) 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 4: Don't 'kill -9' the postmaster
[HACKERS] QNX : POSSIBLE BUG IN CONFIGURE ?
Hi all As I posted few days ago I started checking postgresql 7.1RC1 in QNX 4.25. The last I checked was 7.1b3. the problem is : whenI execute configure it recognize the executable suffix as .map and this is not right. And the test program fails. If I try the same in 7.1b3 all works good. Then I tried to modify configure : line 1472 *.c | *.o | *.obj | *.map) ;; // I added *.map With this all works. I can compile but when I run initdb it crashes. this is the output file --- Running with debug mode on.Initdb variables: PGDATA=/usr/local/pgsql/data1 datadir=/usr/local/pgsql/share PGPATH=//1/usr/local/pgsql/bin TEMPFILE=/tmp/initdb.25146 MULTIBYTE= MULTIBYTEID=0 POSTGRES_SUPERUSERNAME=maurizio POSTGRES_SUPERUSERID=100 TEMPLATE1_BKI=/usr/local/pgsql/share/template1.bki GLOBAL_BKI=/usr/local/pgsql/share/global.bki TEMPLATE1_DESCR=/usr/local/pgsql/share/template1.description GLOBAL_DESCR=/usr/local/pgsql/share/global.description POSTGRESQL_CONF_SAMPLE=/usr/local/pgsql/share/postgresql.conf.sample PG_HBA_SAMPLE=/usr/local/pgsql/share/pg_hba.conf.sample PG_IDENT_SAMPLE=/usr/local/pgsql/share/pg_ident.conf.sampleThis database system will be initialized with username "maurizio".This user will own all the data files and must also own the server process.Creating directory /usr/local/pgsql/data1Creating directory /usr/local/pgsql/data1/baseCreating directory /usr/local/pgsql/data1/globalCreating directory /usr/local/pgsql/data1/pg_xlogCreating template1 database in /usr/local/pgsql/data1/base/1Running: //1/usr/local/pgsql/bin/postgres -boot -x1 -C -F -D/usr/local/pgsql/data1 -d template1DEBUG: database system was shut down at 2001-04-02 10:59:31 cestDEBUG: CheckPoint record at (0, 8)DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUEDEBUG: NextTransactionId: 514; NextOid: 16384DEBUG: database system is in production stateproname name proowner int4 prolang oid proisinh bool proistrusted bool proiscachable bool proisstrict bool pronargs int2 proretset bool prorettype oid proargtypes oidvector probyte_pct int4 properbyte_cpu int4 propercall_cpu int4 prooutin_ratio int4 prosrc text probin bytea creating bootstrap relationbootstrap relation created ok Commit Endtuple 1242Inserting value: 'boolin'Typ == NULL, typeindex = 3 idx = 0boolin End InsertValueInserting value: '100'Typ == NULL, typeindex = 6 idx = 1100 End InsertValueInserting value: '12'Typ == NULL, typeindex = 9 idx = 212 End InsertValueInserting value: 'f'Typ == NULL, typeindex = 0 idx = 3f End InsertValueInserting value: 't'Typ == NULL, typeindex = 0 idx = 4t End InsertValueInserting value: 't'Typ == NULL, typeindex = 0 idx = 5t End InsertValueInserting value: 't'Typ == NULL, typeindex = 0 idx = 6t End InsertValueInserting value: '1'Typ == NULL, typeindex = 4 idx = 71 End InsertValueInserting value: 'f'Typ == NULL, typeindex = 0 idx = 8f End InsertValueInserting value: '16'Typ == NULL, typeindex = 9 idx = 916 End InsertValueInserting value: '0'Typ == NULL, typeindex = 13 idx = 10End InsertValueInserting value: '100'Typ == NULL, typeindex = 6 idx = 11100 End InsertValueInserting value: '0'Typ == NULL, typeindex = 6 idx = 120 End InsertValueInserting value: '0'Typ == NULL, typeindex = 6 idx = 130 End InsertValueInserting value: '100'Typ == NULL, typeindex = 6 idx = 14100 End InsertValueInserting value: 'boolin'Typ == NULL, typeindex = 8 idx = 15boolin End InsertValueInserting value: '-'Typ == NULL, typeindex = 1 idx = 16- End InsertValueInsert BeginInsertOneTuple oid 1242, 17 attrs- I don't know how configure works but from 7.1b3 to 7.1RC1 something was changed in it and I think this is the problem in QNX. I also checked my coimpiler but I can compile all but the last postgresql version. Could You help me ? Thanks. Maurizio CauciDREAMTECH di Cauci MaurizioVia Ronchetti, 2 - 21013 Gallarate (VA)www.dreamtech-it.com
Re: [HACKERS] CVS commits
will still get into v7.1 *nod*
On Mon, 2 Apr 2001, Michael Meskes wrote:
Will current CVS commits make it into 7.1? Or do I have to use a different
branch. I just committed a minor patch to keep the parsers in sync and also
committed a bug fix last week. Both should be in 7.1.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bug in user-defined types?
Adriaan Joubert [EMAIL PROTECTED] writes: In response to comments made here, I have been rewriting the unsigned types as externally loadable. Using the same routines that worked fine when linked statically into the backend gives me core-dumps only. Seems unlikely that that code could have worked either way, since you forgot to mark type uint2 as PASSEDBYVALUE... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!!HELP
Patch applied, with wording modifications by Tom Lane.
Hi
Regarding my previous post, I just successfully created a unique index on
pg_shadow. DON'T DO THIS!!!
---
CREATE UNIQUE INDEX shadow_index ON pg_shadow (usename)
---
I couldn't create at pg_shadow_index as the pg prefix is reserved for
system tables.
This BROKE the database. At least I can't connect anymore with a:
---
template1=# \c statements
FATAL 1: Index 'pg_shadow_name_index' does not exist
Previous connection kept
template1=#
---
If I look at the error log I get :
---
ERROR: Illegal class name 'pg_shadow_index'
The 'pg_' name prefix is reserved for system catalogs
ERROR: Index 'pg_shadow_name_index' does not exist
ERROR: SearchSysCache: recursive use of cache 23
ERROR: SearchSysCache: recursive use of cache 23
ERROR: SearchSysCache: recursive use of cache 23
ERROR: SearchSysCache: recursive use of cache 23 -- quite psql here
FATAL 1: Index 'pg_shadow_name_index' does not exist -- restarted again
FATAL 1: Index 'pg_shadow_name_index' does not exist
FATAL 1: Index 'pg_shadow_name_index' does not exist
---
What can I do??? I've got a non-trivial amount of data that I cannot afford
to lose!! HELP!..
First, here is a patch which will prevent this from happening in the
future. Do people want this held for 7.2 or applied now? It disables
the creation of user indexes on system tables.
The user-defined indexes on system columns can not be made to work
easily. Tom Lane pointed out to me in a phone call that code like:
CatalogIndexInsert(irelations, Num_pg_class_indices, relrelation, reltup);
assumes it knows the number of indexes on each system table, and a
user-defined one would not be updated by any system catalog change that
did not go through the executor.
As far as recovery, I am not sure. One issue is that pg_shadow is a
global table, not local to the database. My guess is that the global
table is still fine, but the index is in the database where you created
the index. You can't remove the file because pg_index thinks the index
is proper and exists.
I am kind of stumped.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Index: src/backend/catalog/index.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/catalog/index.c,v
retrieving revision 1.144
diff -c -r1.144 index.c
*** src/backend/catalog/index.c 2001/03/22 06:16:10 1.144
--- src/backend/catalog/index.c 2001/03/30 22:55:54
***
*** 864,869
--- 864,876
indexInfo-ii_NumKeyAttrs 1)
elog(ERROR, "must index at least one attribute");
+ if (heapRelationName !allow_system_table_mods
+ IsSystemRelationName(heapRelationName) IsNormalProcessingMode())
+ {
+ elog(ERROR, "You can not create indexes on system tables: '%s'",
+ heapRelationName);
+ }
+
/*
* get heap relation oid and open the heap relation
*/
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX onPG_SHADOW Dont!! HELP
Bruce Momjian writes: + elog(ERROR, "You can not create indexes on system tables: %s'", +heapRelationName); One of these days we should decide on a spelling of "indexes" vs "indices". -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOWDont!! HELP
Bruce Momjian writes: + elog(ERROR, "You can not create indexes on system tables: %s'", +heapRelationName); One of these days we should decide on a spelling of "indexes" vs "indices". Yes. Added to TODO: * Decide on spelling of indexes/indices -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Irix binaries of 7.1 RC1 are available
Binaries for PostgreSQL 7.1 RC1 are now available in ftp://ftp.postgresql.org/pub/binary/v7.1/IRIX_6.5.7/ All regression tests pass except that geometry is different by very small amounts ( 10^14) and join gives the same rows in a different order. +--++ | Robert E. Bruccoleri, Ph.D. | Phone: 609 737 6383| | President, Congenomics, Inc. | Fax: 609 737 7528| | 114 W Franklin Ave, Suite K1,4,5 | email: [EMAIL PROTECTED]| | P.O. Box 314 | URL: http://www.congen.com/~bruc | | Pennington, NJ 08534 || +--++ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Shouldn't ON UPDATE/DELETE triggers be BEFORE triggers?
While thinking over Jeremy Radlow's recent problem report in pgsql-general, it occurs to me that it's probably wrong to implement referential integrity actions like ON CASCADE DELETE in AFTER triggers. Seems to me that this breaks the fundamental rule of referential integrity: if B references A then there must always be a matching A row for every B row. Therefore, if we delete a row from A we should delete the matching B row(s) before, not after, we delete from A. Otherwise the remainder of the transaction sees an illegal state of the database. Comments? How about ON UPDATE actions? 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] Re: Changing the default value of an inherited column
Tom Lane writes: Well, we *do* have a syntax for specifying a new default (the same one that worked pre-7.0 and does now again). I guess what you are proposing is the rule "If conflicting default values are inherited from multiple parents that each define the same column name, then an error is reported unless the child table redeclares the column and specifies a new default to override the inherited ones". This was the idea. If it's to complicated to do now, let's at least keep it in mind. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Update HISTORY/release.sgml
I have updated HISTORY/release.sgml to contain the most recent changes for 7.1. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Shouldn't ON UPDATE/DELETE triggers be BEFORE triggers?
While thinking over Jeremy Radlow's recent problem report in pgsql-general, it occurs to me that it's probably wrong to implement referential integrity actions like ON CASCADE DELETE in AFTER triggers. Seems to me that this breaks the fundamental rule of referential integrity: if B references A then there must always be a matching A row for every B row. Therefore, if we delete a row from A we should delete the matching B row(s) before, not after, we delete from A. Otherwise the remainder of the transaction sees an illegal state of the database. If we're right in how we read the spec, then this isn't an illegal state except for non-deferred constraints and then only for the period between the delete and the after trigger running. Note: I think we may be misinterpreting the spec here (more below), but if our interpretation, deferred actions occur at end of transaction, is correct, then the "invalid" state is valid to see for the rest of transaction in that case. Comments? How about ON UPDATE actions? However, I think that the intention was to have actions (obviously other than NO ACTION) occur immediately even on deferred constraints. I say this because the sections on figuring matching and uniquely matching rows makes little sense if the action could be deferred and IIRC it says things like "if a row is marked for removal" rather than "at the time of checking a constraint, if a row was marked for removal." When I tried this in Oracle a while ago, this was also what they did. A deferred constraint with a cascade would kill the referencing rows after the delete so you wouldn't see them for the rest of the transaction. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Changing the default value of an inherited column
On Sun, Apr 01, 2001 at 03:15:56PM -0400, Tom Lane wrote: Christopher Masto [EMAIL PROTECTED] writes: Another thing that seems kind of interesting would be to have: CREATE TABLE base (table_id CHAR(8) NOT NULL [, etc.]); CREATE TABLE foo (table_id CHAR(8) NOT NULL DEFAULT 'foo'); CREATE TABLE bar (table_id CHAR(8) NOT NULL DEFAULT 'bar'); Then a function on "base" could look at table_id and know which table it's working on. A waste of space, but I can think of uses for it. This particular need is superseded in 7.1 by the 'tableoid' pseudo-column. However you can certainly imagine variants of this that tableoid doesn't handle, for example columns where the subtable creator can provide a useful-but-not-always-correct default value. A bit of O-O doctrine... when you find yourself tempted to do something like the above, it usually means you're trying to do the wrong thing. You may not have a choice, in some cases, but you should know you are on the way to architecture meltdown. "She'll blow, Cap'n!" Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Changing the default value of an inherited column
On Mon, Apr 02, 2001 at 01:27:06PM -0400, Tom Lane wrote: Philip: the rule that pg_dump needs to apply w.r.t. defaults for inherited fields is that if an inherited field has a default and either (a) no parent table supplies a default, or (b) any parent table supplies a default different from the child's, then pg_dump had better emit the child field explicitly. The rule above appears to work even if inherited-default conflicts are not taken as an error, but just result in a derived-table column with no default. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Changing the default value of an inherited column
[EMAIL PROTECTED] (Nathan Myers) writes: On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote: That is: create table p1 (f1 int default 1); create table p2 (f1 int default 2); create table c1 (f2 float) inherits(p1, p2); # XXX would draw an error about conflicting defaults for c1.f1, but create table c1 (f1 int default 3, f2 float) inherits(p1, p2); would be accepted (and 3 would become the default for c1.f1). This would take a few more lines of code, but I'm willing to do it if people think it's a safer behavior than picking one of the inherited default values. Allowing the line marked XXX above, but asserting no default for c1.f1 in that case, would be equally safe. (A warning would be polite, anyhow.) The trouble with that is that we don't have such a concept as "no default", if by that you mean "INSERTs *must* specify a value". What would really happen would be that the effective default would be NULL, which I think would be fairly surprising behavior, since none of the three tables involved asked for that. I have committed code that raises an error in cases such as XXX above. Let's try it like that for awhile and see if anyone complains ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Changing the default value of an inherited column
At 13:27 2/04/01 -0400, Tom Lane wrote: Philip: the rule that pg_dump needs to apply w.r.t. defaults for inherited fields is that if an inherited field has a default and either (a) no parent table supplies a default, or (b) any parent table supplies a default different from the child's, then pg_dump had better emit the child field explicitly. What is happening with IS NULL constraints (and type names)? I presume the above rule should be applied to each of these fields? 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] Re: Changing the default value of an inherited column
Philip Warner [EMAIL PROTECTED] writes: At 13:27 2/04/01 -0400, Tom Lane wrote: Philip: the rule that pg_dump needs to apply w.r.t. defaults for inherited fields is that if an inherited field has a default and either (a) no parent table supplies a default, or (b) any parent table supplies a default different from the child's, then pg_dump had better emit the child field explicitly. What is happening with IS NULL constraints (and type names)? NOT NULL on a child field would only force it to be dumped if none of the parents say NOT NULL. Type name really is not an issue since it will have to be the same in all the tables anyway; I wouldn't bother expending any code there. 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] Do we have any platforms that allow null pointer dereference?
Do we have any supported platforms where dereferencing a null pointer doesn't trigger coredump? I'm wondering about this after noticing the likely side effects of fd.c's failure to check for null result from malloc(): it'll try to strcpy() filenames to location zero. If it succeeds, you could end up with multiple VFDs sharing the same filename string. Which could lead to, eg, writing on or even deleting one file under the delusion that we were writing/deleting another. With sufficient suspension of disbelief about how long a backend could run at zero free memory before elog'ing, this might explain the two recent reports of Postgres apparently deleting a file it shouldn't have. (I'm not sure I really believe that, but given the way palloc works it's not out of the question. I've added appropriate checks to fd.c, just in case.) AFAIK, null pointer deref - SIGSEGV is standard behavior on most platforms these days, and we take steps to select that behavior on some nonconformists like HPUX. But I'm wondering if there are any platforms we could select it on and have forgotten to. I think it would be a real good idea to turn on null pointer crash anywhere we can. 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] Bug in user-defined types?
Tom Lane wrote: Seems unlikely that that code could have worked either way, since you forgot to mark type uint2 as PASSEDBYVALUE... Aargh! Thanks! Yes, when implementing it in the backend, that was just a field to fill in, so I did it there. All seems well now. One ends up with a vast number of combinations of types combinations for different operators. As C takes care of the conversions, I wrote a 30-line perl script to generate me nearly 1600 lines of C for all the type combinations (+ ~1700 lines of sql to define the functions/operators). I cannot help feeling that that is not the right way: if it can be done in a few lines of perl and relies on C cross-type operations underneath anyway, it seems wrong to have to generate all this code. The problem is that there is not a clean hierarchy of SQL types, but for many cases one could either convert the operands to int4 or float8 and then numeric(?) and then convert back. At least the conversion operators check for overflow, which is better than the current situation. And precision wise it cannot be much worse: after all, large integer constants already end up as floats. Is the SQL standard pedantic about this? BTW I could not find the discussion on entry-points to shared libraries that Thomas mentioned. I've got some rushed dead-lines at the moment, so I will not be able to look at anything for the next 3-4 weeks though. Adriaan ---(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] Re: Changing the default value of an inherited column
At 23:57 2/04/01 -0400, Tom Lane wrote:
NOT NULL on a child field would only force it to be dumped if none
of the parents say NOT NULL. Type name really is not an issue since
it will have to be the same in all the tables anyway; I wouldn't bother
expending any code there.
I've made tha changes and it all seems to work, bu there is a minor
inconsistency:
create table p3_def1(f1 int default 1, f2 int);
create table c5(f1 int not null, f3 int) inherits(p3_def1);
c5 gets dumped as:
CREATE TABLE "c5" (
"f1" integer DEFAULT 1 NOT NULL,
"f3" integer
)
inherits ("p3_def1");
since the NOT NULL forces the field to dump, and it is dumps as though it
were a real field.
Similarly,
create table p2_nn(f1 int not null, f2 int not null);
create table c6(f1 int default 2, ,f3 int) inherits(p2_nn);
results in C6 being dumped as:
CREATE TABLE "c6" (
"f1" integer DEFAULT 2 NOT NULL,
"f3" integer
)
inherits ("p2_nn");
I think it needs to dump ONLY the overridden settigns, since a change to
the overriding behaviour of a child seems like a bad thing.
What do you think?
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 4: Don't 'kill -9' the postmaster
