Re: [HACKERS] More DROP COLUMN
On Mon, 2002-07-15 at 06:06, Christopher Kings-Lynne wrote: We could name the fields dropped_x sort of thing perhaps In practice that would certainly work, especially if we increase NAMEDATALEN to 128 or so, as has been proposed repeatedly. Well, x is just an integer anyway, so even with 32 it's not a problem... In case anyone was wondering btw, if a column named 'dropped_1' already exists when you drop column 1 in the table, it will be renamed like this: dropped1_1 And if that also exists, it will become dropped2_1 etc. I put that extra number after dropped and not at the end so prevent it being off the end of a 32 character name. Alternatively, we could invest a lot of work to make it possible for attname to be NULL, but I don't see the payoff... Yeah, I think a weird name should be good enough... perhaps starting it with spaces instead of _ would make it even harder to write by accident, so tha name could be dropped 01 or to make it even more self documenting store the drop time, col001 [EMAIL PROTECTED] --- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] More DROP COLUMN
etc. I put that extra number after dropped and not at the end so prevent it being off the end of a 32 character name. Alternatively, we could invest a lot of work to make it possible for attname to be NULL, but I don't see the payoff... Yeah, I think a weird name should be good enough... perhaps starting it with spaces instead of _ would make it even harder to write by accident, so tha name could be dropped 01 or to make it even more self documenting store the drop time, col001 [EMAIL PROTECTED] Well, are there characters that are illegal in column names that I could use? I did a quick check and couldn't find any! Chris ---(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] More DROP COLUMN
However, I'm not happy with the way dropped columns are renamed. I want to give them a name that no-one would ever want to use as a legit column name. I don't like this behaviour: Yes, how about prepending a character that would usually need to be escaped. I like Hannu's proposal with the blanks col1 [EMAIL PROTECTED]:30:00, the underscores are too commonly used. Maybe add two characters, one special and a backspace after the first blank. So it would print nicely, but be very unlikely. I would prefer a simple but highly predictable rule, where you can say Don't name your columns starting with \353\010 (blank, greek d, BS) over some random algo that stays out of the way by means of low probability. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] More DROP COLUMN
On Mon, 2002-07-15 at 09:20, Christopher Kings-Lynne wrote: etc. I put that extra number after dropped and not at the end so prevent it being off the end of a 32 character name. Alternatively, we could invest a lot of work to make it possible for attname to be NULL, but I don't see the payoff... Yeah, I think a weird name should be good enough... perhaps starting it with spaces instead of _ would make it even harder to write by accident, so tha name could be dropped 01 or to make it even more self documenting store the drop time, col001 [EMAIL PROTECTED] Well, are there characters that are illegal in column names that I could use? I did a quick check and couldn't find any! I guess that \0 would be unusable (not sure if its illegal) \r \n and \t (and others 0x20) are probably quite unlikely too. -- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] advice for user column named cmin
I'm trying to use a closed source program with PostgreSQL over ODBC The problem is that it tries to make a table which has a column called 'cmin' which of course not allowes. Are there any plans of either 1) (optionally) renaming such sytem columns in the ODBC layer 2) renaming system colums to start with pg_ (pg_oid, pg_cmin, pg_*) 3) moving them to another namespace, accessible like a schema so select oid from mytable; would become select system.oid from mytable; I quess that SQL is not as flexible as XML in putting anything in its own namespace ;( --- Hannu ---(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] More DROP COLUMN
On Mon, 15 Jul 2002, Zeugswetter Andreas SB SD wrote: I would prefer a simple but highly predictable rule, where you can say Don't name your columns starting with \353\010 (blank, greek d, BS) over some random algo that stays out of the way by means of low probability. \353 is not a delta in most of the character encodings that I use, and is not valid at all in ASCII. Non-graphic chars are also likely to cause misery because it's not obvious, using normal tools, what they are. (The above example would appear to many people as just a space.) I would suggest it's probably a good idea to stick to ASCII graphic (i.e., non-control, not delete) characters. 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] More DROP COLUMN
Hannu Krosing [EMAIL PROTECTED] writes: or to make it even more self documenting store the drop time, col001 [EMAIL PROTECTED] I'm not at all excited about trying to store times, random numbers, etc in dropped column names. We are not trying to do cryptography here, only invent an improbable name. I do not believe that injecting pseudo-randomness will help. I'd prefer to keep the names of dropped columns predictable. I guess that \0 would be unusable (not sure if its illegal) You can NOT use \0, and I don't think other nonprinting characters would be a good idea either. I think a bunch of leading spaces or underscores would be fine. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] DROP COLUMN
OK, more DROP COLUMN funny business: Assuming that selects, updates and deletes all ignore the dropped column, what happens with things like alter table statements? You can still quite happily set the default for a dropped column, etc. Will I have to add a dropped column check in everywhere that a command is able to target a column. ie. create index, cluster, alter table, etc, etc.? Or is there an easier way? Cheers, Chris ---(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] fmtId() and pg_dump
The fmtId() function used in pg_dump for optional quoting identifiers has bothered me for a while now. The API is confusing: the returned value needs to be used before fmtId() is called again, because the buffer the return value points to is re-used for each call of fmtId(). That leads to bugs for those unaware of this requirement, and clumsy code for those that are -- for example (pg_dump.c:2911) appendPQExpBuffer(delq, DROP TYPE %s., fmtId(tinfo-typnamespace-nspname, force_quotes)); appendPQExpBuffer(delq, %s;\n, fmtId(tinfo-typname, force_quotes)); Should really only be 1 line of code. Similar ugliness occurs in many places (e.g. several lines down, there is a section of 4 calls to appendPQExpBuffer() that could be condensed down to 1, if not for fmtId() ). Lastly, it has a tendancy to produce memory leaks -- for example, convertRegProcReference() in pg_dump.c will leak memory when used with PostgreSQL = 7.3. When I mentioned this to Tom Lane, he said that he didn't see a way to fix it without convoluting the code, and suggested I bring it up on -hackers. My suggestion is: since fmtId() is almost always used with appendPQExpBuffer(), we should add a wrapper function to pg_dump that accepts an extra escape sequence (%S, or %i, perhaps), which would properly quote the input string before passing it to appendPQExpBuffer(). That should ensure that there won't be any leaks from adding quotes to identifiers, but also allow us to avoid playing games with static buffers, like fmtId() does now. Any comments? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] COPY x FROM STDIN escape handlers
Just to give a little background, using pgdump in default mode creates a dump file that includes inline newlines and tabs. The solution is to use the -Fc option but it's a little late for that if all one has is a default dump file. I was hoping to simply run a conversion on the file to create an escaped version of the file, but none of the traditional escape methods appear to work (ie. \n, \010, 0x10, etc). The code errors out in CopyReadNewline() but it's the result of a call from CopyFrom(). From what I can see, there is no escape handler in the CopyFrom function. So, should this be considered an enhancement or is there an underlying reason why it isn't there? If it's an enhancement, I'll patch it and submit it but I *really* don't want to end up with a non-standard version of PostgreSQL! Thanks in advance! Marc L. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
On Mon, 2002-07-15 at 11:30, Christopher Kings-Lynne wrote: OK, more DROP COLUMN funny business: Assuming that selects, updates and deletes all ignore the dropped column, what happens with things like alter table statements? You can still quite happily set the default for a dropped column, etc. Will I have to add a dropped column check in everywhere that a command is able to target a column. ie. create index, cluster, alter table, etc, etc.? Or is there an easier way? Each utility statement does some kind of a SearchSysCache() to determine the status of the column (whether it exists or not). You may want to write a wrapper function in lsyscache.c that returns the status of the column (dropped or not). Perhaps the att tuple could be fetched through this function (processed on the way out) -- though lsyscache routines tend to return simple items. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN
Rod Taylor wrote: On Mon, 2002-07-15 at 11:30, Christopher Kings-Lynne wrote: OK, more DROP COLUMN funny business: Assuming that selects, updates and deletes all ignore the dropped column, what happens with things like alter table statements? You can still quite happily set the default for a dropped column, etc. Will I have to add a dropped column check in everywhere that a command is able to target a column. ie. create index, cluster, alter table, etc, etc.? Or is there an easier way? Each utility statement does some kind of a SearchSysCache() to determine the status of the column (whether it exists or not). You may want to write a wrapper function in lsyscache.c that returns the status of the column (dropped or not). Perhaps the att tuple could be fetched through this function (processed on the way out) -- though lsyscache routines tend to return simple items. Excellent idea. That's how temp tables worked, by bypassing the syscache. I wonder if you could just prevent dropped columns from being returned by the syscache. That may work just fine. -- 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] DROP COLUMN
Bruce Momjian [EMAIL PROTECTED] writes: Excellent idea. That's how temp tables worked, by bypassing the syscache. I wonder if you could just prevent dropped columns from being returned by the syscache. That may work just fine. No, it will break all the places that need to see dropped columns. I agree that a wrapper function is probably an appropriate solution, but only some of the calls of SearchSysCache should use it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] COPY x FROM STDIN escape handlers
I see the problem now. It was my file parser that was escaping the value then passing it to PQescapeString which resulted in \\n instead of \n. Guess I was on a wild goose chase. I guess PQescapeString() and PQputline() are mutally exclusive ... my bad! Thanks, Marc L. Tom Lane wrote: Marc Lavergne [EMAIL PROTECTED] writes: Just to give a little background, using pgdump in default mode creates a dump file that includes inline newlines and tabs. How old a PG release are you using? COPY has quoted special characters properly for a long time. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] More DROP COLUMN
chris, have you looked at how sapdb (http://www.sapdb.org) does this ? /sergio ps: IANAL Christopher Kings-Lynne [EMAIL PROTECTED] escribió en el mensaje [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... OK, DROP COLUMN now seems to work perfectly. All the old test cases that failed now work fine. However, I'm not happy with the way dropped columns are renamed. I want to give them a name that no-one would ever want to use as a legit column name. I don't like this behaviour: test=# create table test (a int4, b int4); CREATE TABLE test=# alter table test drop a; ALTER TABLE test=# select dropped_1 from test; ERROR: Attribute dropped_1 not found test=# alter table test add dropped_1 int4; ERROR: ALTER TABLE: column name dropped_1 already exists in table test It's a bit confusing, hey? What should we do about it? Maybe I could make ADD COLUMN give this message instead for dropped columns? ERROR: ALTER TABLE: column name dropped_1 is a dropped column in table test ... or something ... We could name the fields dropped_x sort of thing perhaps Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] COPY x FROM STDIN escape handler
Can somebody point me to any escape handlers in the COPY mechanism. I have grepped and examined to the best of my ability and haven't found any indication that there even is an escape handler around COPY. Just to give a little background, using pgdump in default mode creates a dump file that includes inline newlines and tabs. The solution is to use the -Fc option but it's a little late for that if all one has is a default dump file. I was hoping to simply run a conversion on the file to create an escaped version of the file, but none of the traditional escape methods appear to work (ie. \n, \010, 0x10, etc). Am I correct that there is no escape handler in the COPY command. If so, should this be considered an enhancement or is there an underlying reason why it isn't there. Also, in the case this is an enhancement, where in the code would this kind of mechanism be appropriate (ie. interface, back end, parser, etc.). Wow ... nice sentence. ;-) Thanks in advance! Marc L. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] HeapTuple header changes cause core dumps in CVS tip
An example is:
regression=# create table foo (f1 text);
CREATE TABLE
regression=# insert into foo values ('z');
INSERT 148289 1
regression=# insert into foo select * from foo;
INSERT 148290 1
regression=# insert into foo select * from foo;
INSERT 0 2
regression=# insert into foo select * from foo;
INSERT 0 4
repeat enough times to have 1000 or so tuples in table
regression=# insert into foo values ('q');
INSERT 150337 1
regression=# delete from foo where f1 != 'q';
DELETE 2048
regression=# vacuum full foo;
VACUUM
regression=# update foo set f1 = 'qq';
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Backtracing shows that the assertion in HeapTupleHeaderSetCmax fails,
because it's not expecting to find the HEAP_MOVED bits set in its input.
(The above test is simply an easy way of forcing an update on a tuple
that has been moved by VACUUM FULL.)
I am not sure if this is a bug introduced by the patch, or if it's
exposed a previously lurking bug. It seems that the HEAP_MOVED bits
should be cleared before re-using cmax for something else, but I have
not dug through the old logic to see how it was done before. Or perhaps
we cannot really reduce the number of fields this far.
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] getopt_long search in configure
I have added: AC_CHECK_LIB(getopt, main) to configure.in to allow PostgreSQL to perhaps find getopt_long() in a separate library. -- 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
[HACKERS] Unused system table columns
The following system table columns are currently unused and don't appear to be in the line of resurrection. pg_language.lancompiler pg_operator.oprprec pg_operator.oprisleft pg_proc.probyte_pct pg_proc.properbyte_cpu pg_proc.propercall_cpu pg_proc.prooutin_ratio pg_shadow.usetrace pg_type.typprtlen pg_type.typreceive pg_type.typsend This adds up to quite some space -- on disk and on the screen. I think we should remove them. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] OT: O'Reilly OSCon gatherings
I've been conversing with Bruce off-list about getting people together for dinner one night during next week's OSCon in San Diego. Please email me if you are interested with your preferred day/time and I will try to coordinate something. Also FYI there is a PostgreSQL BOF scheduled: PostgreSQL Date: 07/24/2002 Time: 8:00pm - 9:00pm Location: Grande Ballroom B in the East Tower Moderated by: Bruce Momjian, SRA/Japan Thanks, Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] getopt bug
We had a fixed version of getopt() that would properly warn users that they compiled psql without long options on systems with buggy getopt's, like FreeBSD. Now that I have added a search for libgetopt.a, which may find getopt_long on those platforms, I have removed utils/getopt.c. No modules were using it anyway. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
Tom Lane writes: Also, is the new relfilenode somehow guaranteed to not be assigned to another relation (pg_class tuple, I think)? I've been wondering about that myself. We might have to add a unique index on pg_class.relfilenode to ensure this; otherwise, after OID wraparound there would be no guarantees. I've never been happy with the current setup. It's much too tempting to think file name = OID, both in the backend code and by external onlookers, especially since it's currently rare/impossible(?) for them to be different. It would be a lot clearer if relfilenode were replaced by an integer version, starting at 0, and the heap files were named OID_VERSION. (In related news, how about filling up the oid/relfilenode numbers with zeros on the left, so a directory listing would reflect the numerical order?) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] plpgsql and Schemas
Rod Taylor writes: I've been running a few functions within schema's. It's annoying that everything needs to be qualified as it doesn't allow the functions to be moved very easily. Would it be appropriate for the function to have it's own schema as pre-pended onto the user path while in the users function? The SQL standard has rules on how the effective schema path during a function execution is determined. In a nutshell, it allows you to specify the path as an attribute of the containing schema. E.g., CREATE SCHEMA foo PATH here, there; I haven't thought this through, but you might want to think about it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Future of src/utils
We have src/utils for stuff supposedly that is used by the backend and other binaries, and src/backend/port for stuff used only by the backend. However, over time, this distinction has broken down and we have a number of backend/port stuff used in other binaries. I propose moving the src/utils remaining items into src/backend/port, and removing the src/utils directory. -- 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])
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
Peter Eisentraut wrote: Tom Lane writes: Also, is the new relfilenode somehow guaranteed to not be assigned to another relation (pg_class tuple, I think)? I've been wondering about that myself. We might have to add a unique index on pg_class.relfilenode to ensure this; otherwise, after OID wraparound there would be no guarantees. I've never been happy with the current setup. It's much too tempting to think file name = OID, both in the backend code and by external onlookers, especially since it's currently rare/impossible(?) for them to be different. Yea, only reindex and cluster change them. Problem is we already have oid as a nice unique number ready for use. I don't see a huge advantage of improving it. It would be a lot clearer if relfilenode were replaced by an integer version, starting at 0, and the heap files were named OID_VERSION. Problem there is that we can't have relfilenode as an int unless we take the table oid and sequence number and merge them on the fly in the backend. Would be nice for admins, though, so the oid would be there. I thought WAL liked the relfilenode as a single number. (In related news, how about filling up the oid/relfilenode numbers with zeros on the left, so a directory listing would reflect the numerical order?) Problem there is that we increase the size of much of the directory lookups. Not sure if it is worth worrying about. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Unused system table columns
For all intent and purpose, pg_index.indisprimary can be added to that list. Can't make a primary key without a pg_constraint entry. The below are also reported unused by the documentation: pg_class.relukeys pg_class.relfkeys pg_class.relrefs pg_index.indisclustered pg_index.indreference On Mon, 2002-07-15 at 18:53, Peter Eisentraut wrote: The following system table columns are currently unused and don't appear to be in the line of resurrection. pg_language.lancompiler pg_operator.oprprec pg_operator.oprisleft pg_proc.probyte_pct pg_proc.properbyte_cpu pg_proc.propercall_cpu pg_proc.prooutin_ratio pg_shadow.usetrace pg_type.typprtlen pg_type.typreceive pg_type.typsend This adds up to quite some space -- on disk and on the screen. I think we should remove them. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] getopt_long search in configure
Bruce Momjian writes: I have added: AC_CHECK_LIB(getopt, main) to configure.in to allow PostgreSQL to perhaps find getopt_long() in a separate library. Is there a system that distributes a libgetopt library that contains getopt_long()? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Future of src/utils
Bruce Momjian writes: However, over time, this distinction has broken down and we have a number of backend/port stuff used in other binaries. I propose moving the src/utils remaining items into src/backend/port, and removing the src/utils directory. I propose the reverse operation. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] getopt_long search in configure
Peter Eisentraut wrote: Bruce Momjian writes: I have added: AC_CHECK_LIB(getopt, main) to configure.in to allow PostgreSQL to perhaps find getopt_long() in a separate library. Is there a system that distributes a libgetopt library that contains getopt_long()? I have it here in /usr/local/include. Not sure how it got there. It must have been installed by some other software. -- 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] Future of src/utils
Peter Eisentraut wrote: Bruce Momjian writes: However, over time, this distinction has broken down and we have a number of backend/port stuff used in other binaries. I propose moving the src/utils remaining items into src/backend/port, and removing the src/utils directory. I propose the reverse operation. Yea, I thought of that. Means all the subdirectores have to move too. It is more extreme than moving stuff from /src/utils, but it is more logical. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HeapTuple header changes cause core dumps in CVS tip
On Mon, 15 Jul 2002 16:46:44 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
regression=# update foo set f1 = 'qq';
server closed the connection unexpectedly
Same with DELETE FROM foo;
I am not sure if this is a bug introduced by the patch, or if it's
exposed a previously lurking bug.
I suspect the former :-(
It seems that the HEAP_MOVED bits
should be cleared before re-using cmax for something else, but I have
not dug through the old logic to see how it was done before.
AFAICS from a quick look at tqual it didn't matter before. Once the
vacuum transaction had committed, on the next access to the tuple
MOVED_IN caused XMIN_COMMITTED to be set, and after that the MOVED
bits were never looked at again. MOVED_OFF is not an issue.
I'll take a closer look at tqual and the vacuum source code tomorrow.
For now the attached patch cures both symptoms (UPDATE and DELETE) and
passes all regression tests. A regression test for this case will
follow.
Servus
Manfred
diff -ruN ../base/src/backend/access/heap/heapam.c src/backend/access/heap/heapam.c
--- ../base/src/backend/access/heap/heapam.c2002-07-15 22:22:28.0 +0200
+++ src/backend/access/heap/heapam.c2002-07-16 00:16:59.0 +0200
@@ -1123,11 +1123,11 @@
CheckMaxObjectId(HeapTupleGetOid(tup));
}
+ tup-t_data-t_infomask = ~(HEAP_XACT_MASK);
HeapTupleHeaderSetXmin(tup-t_data, GetCurrentTransactionId());
HeapTupleHeaderSetCmin(tup-t_data, cid);
HeapTupleHeaderSetXmaxInvalid(tup-t_data);
- HeapTupleHeaderSetCmax(tup-t_data, FirstCommandId);
- tup-t_data-t_infomask = ~(HEAP_XACT_MASK);
+ /* HeapTupleHeaderSetCmax(tup-t_data, FirstCommandId); */
tup-t_data-t_infomask |= HEAP_XMAX_INVALID;
tup-t_tableOid = relation-rd_id;
@@ -1321,7 +1321,7 @@
START_CRIT_SECTION();
/* store transaction information of xact deleting the tuple */
- tp.t_data-t_infomask = ~(HEAP_XMAX_COMMITTED |
+ tp.t_data-t_infomask = ~(HEAP_XMAX_COMMITTED | HEAP_MOVED |
HEAP_XMAX_INVALID |
HEAP_MARKED_FOR_UPDATE);
HeapTupleHeaderSetXmax(tp.t_data, GetCurrentTransactionId());
HeapTupleHeaderSetCmax(tp.t_data, cid);
@@ -1554,7 +1554,7 @@
_locked_tuple_.tid = oldtup.t_self;
XactPushRollback(_heap_unlock_tuple, (void *) _locked_tuple_);
- oldtup.t_data-t_infomask = ~(HEAP_XMAX_COMMITTED |
+ oldtup.t_data-t_infomask = ~(HEAP_XMAX_COMMITTED | HEAP_MOVED |
HEAP_XMAX_INVALID |
HEAP_MARKED_FOR_UPDATE);
oldtup.t_data-t_infomask |= HEAP_XMAX_UNLOGGED;
@@ -1645,7 +1645,7 @@
}
else
{
- oldtup.t_data-t_infomask = ~(HEAP_XMAX_COMMITTED |
+ oldtup.t_data-t_infomask = ~(HEAP_XMAX_COMMITTED | HEAP_MOVED |
HEAP_XMAX_INVALID |
HEAP_MARKED_FOR_UPDATE);
HeapTupleHeaderSetXmax(oldtup.t_data, GetCurrentTransactionId());
@@ -1816,7 +1816,7 @@
((PageHeader) BufferGetPage(*buffer))-pd_sui = ThisStartUpID;
/* store transaction information of xact marking the tuple */
- tuple-t_data-t_infomask = ~(HEAP_XMAX_COMMITTED | HEAP_XMAX_INVALID);
+ tuple-t_data-t_infomask = ~(HEAP_XMAX_COMMITTED | HEAP_XMAX_INVALID |
+HEAP_MOVED);
tuple-t_data-t_infomask |= HEAP_MARKED_FOR_UPDATE;
HeapTupleHeaderSetXmax(tuple-t_data, GetCurrentTransactionId());
HeapTupleHeaderSetCmax(tuple-t_data, cid);
@@ -2147,7 +2147,7 @@
if (redo)
{
- htup-t_infomask = ~(HEAP_XMAX_COMMITTED |
+ htup-t_infomask = ~(HEAP_XMAX_COMMITTED | HEAP_MOVED |
HEAP_XMAX_INVALID |
HEAP_MARKED_FOR_UPDATE);
HeapTupleHeaderSetXmax(htup, record-xl_xid);
HeapTupleHeaderSetCmax(htup, FirstCommandId);
@@ -2320,7 +2320,7 @@
}
else
{
- htup-t_infomask = ~(HEAP_XMAX_COMMITTED |
+ htup-t_infomask = ~(HEAP_XMAX_COMMITTED | HEAP_MOVED |
HEAP_XMAX_INVALID |
HEAP_MARKED_FOR_UPDATE);
HeapTupleHeaderSetXmax(htup, record-xl_xid);
HeapTupleHeaderSetCmax(htup, FirstCommandId);
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Unused system table columns
On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote: The following system table columns are currently unused and don't appear to be in the line of resurrection. pg_language.lancompiler pg_operator.oprprec pg_operator.oprisleft pg_proc.probyte_pct pg_proc.properbyte_cpu pg_proc.propercall_cpu pg_proc.prooutin_ratio pg_shadow.usetrace pg_type.typprtlen pg_type.typreceive pg_type.typsend pg_type.typreceive and pg_type.typsend are unused, but I think they should be saved for use as converters from/to unified binary wire protocol (as their name implies ;) once we get at it. The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. --- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Unused system table columns
Hannu Krosing wrote: On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote: The following system table columns are currently unused and don't appear to be in the line of resurrection. pg_language.lancompiler pg_operator.oprprec pg_operator.oprisleft pg_proc.probyte_pct pg_proc.properbyte_cpu pg_proc.propercall_cpu pg_proc.prooutin_ratio pg_shadow.usetrace pg_type.typprtlen pg_type.typreceive pg_type.typsend pg_type.typreceive and pg_type.typsend are unused, but I think they should be saved for use as converters from/to unified binary wire protocol (as their name implies ;) once we get at it. The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. We can always re-add the columns them. -- 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])
Re: [HACKERS] Unused system table columns
On Tue, 2002-07-16 at 04:55, Bruce Momjian wrote: Hannu Krosing wrote: On Tue, 2002-07-16 at 03:53, Peter Eisentraut wrote: The following system table columns are currently unused and don't appear to be in the line of resurrection. pg_language.lancompiler pg_operator.oprprec pg_operator.oprisleft pg_proc.probyte_pct pg_proc.properbyte_cpu pg_proc.propercall_cpu pg_proc.prooutin_ratio pg_shadow.usetrace pg_type.typprtlen pg_type.typreceive pg_type.typsend pg_type.typreceive and pg_type.typsend are unused, but I think they should be saved for use as converters from/to unified binary wire protocol (as their name implies ;) once we get at it. The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. We can always re-add the columns them. But would it not be nice if we could add uniform binary protocol without requiring initdb ? If the main concern is disk space, just set them to NULL . Hannu ---(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] Unused system table columns
Hannu Krosing wrote: The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. We can always re-add the columns them. But would it not be nice if we could add uniform binary protocol without requiring initdb ? Seems impossible that would ever happen without an initdb. If the main concern is disk space, just set them to NULL . Good point, but it does confuse developers. -- 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] Unused system table columns
On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote: Hannu Krosing wrote: The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. We can always re-add the columns them. But would it not be nice if we could add uniform binary protocol without requiring initdb ? Seems impossible that would ever happen without an initdb. Why? We already have a binary protocol, the only part I see missing for making it _universal_ is binary representation of types + alignment issues. If we just write the functions for typreceive/send (mostly identity+padding for x86, some byte swapping on SPARC (or vice versa)) and start using them when cursor is in binary mode plus we determine minimal acceptable alignments then we are (almost?) there for output. For input, putting in PREPARE/EXECUTE with binary argument passing will likely need initdb (maybe not), but _temporarily_ throwing out _just_ typreceive seems weird. If the main concern is disk space, just set them to NULL . Good point, but it does confuse developers. But it confuses them _less_ than our current practice of putting unused copies of typinput/typoutput there, and nobody seems too confused even now ;) And keeping them as NULL may be used to indicate than no conversion is needed and data can be sent as-is like we do now, so we are even doing the right thing for this scenario, all without any coding ;) -- Hannu ---(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] Unused system table columns
Hannu Krosing wrote: On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote: Hannu Krosing wrote: The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. We can always re-add the columns them. But would it not be nice if we could add uniform binary protocol without requiring initdb ? Seems impossible that would ever happen without an initdb. Why? It is inconceivable we would add such a feature without a major release, and every major release requires an initdb. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Unused system table columns
On Tue, 2002-07-16 at 05:43, Bruce Momjian wrote: Hannu Krosing wrote: On Tue, 2002-07-16 at 05:19, Bruce Momjian wrote: Hannu Krosing wrote: The alternative would be yet another system table which would allow us to support unlimited number of to/from converters for different wire protocols, but it will definitely be easier to start with typreceive/typsend. We can always re-add the columns them. But would it not be nice if we could add uniform binary protocol without requiring initdb ? Seems impossible that would ever happen without an initdb. Why? It is inconceivable we would add such a feature without a major release, and every major release requires an initdb. Even if we change nothing in system tables ;) As I explained, we already have a binary protocol. What I proposed, would make it usable between hosts with different CPU's by inserting appropriate functions for types - without typsend(), i.e typesend=NULL the behaviour would be exactly as it is now, but people would be free to experiment without fatally breaking all other installations. Technically this will probably not extend much beyond modifying function printtup_internal in src/backend/access/common/printtup.c /* * printtup_internal * We use a different data prefix, e.g. 'B' instead of 'D' to * indicate a tuple in internal (binary) form. * * This is largely same as printtup,except we don't use the typout func. * */ static void printtup_internal(HeapTuple tuple, TupleDesc typeinfo, DestReceiver *self) The hard part will be agreeing on the actual data format(s), but this can be postponed by having this implementation where people can experiment. After looking at the code again, it seems that we must have already solved (most) alignment issues in printtup, so the task is just agreeing on types' on-wire representations. -- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Mac OS X: system shutdown prevents checkpoint
From: Tom Lane [EMAIL PROTECTED] Date: Thu, 02 May 2002 00:45:19 -0400 ;;; However, that doesn't explain our OS X problem. I added some debug ;;; printouts, and can now report positively that (a) the fork() call ;;; returns normally in the parent process, providing an apparently-correct ;;; child PID value; but (b) the fork never returns in the child. It ;;; doesn't ever get as far as trying to enable SIGTERM. ;;; Is it possible that something in the child's fork() processing will wait ;;; around for a response from a service that's already died? Why is fork() ;;; dependent on any outside service whatever --- isn't that a certain ;;; recipe for system failures? I asked Apple this issue. This is a bug of Mac OS X. The problem is registered to their bug database for the appropriate eingineers for investigation. Kenji Sugita ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Unused system table columns
Hannu Krosing wrote: Technically this will probably not extend much beyond modifying function printtup_internal in src/backend/access/common/printtup.c /* * printtup_internal * We use a different data prefix, e.g. 'B' instead of 'D' to * indicate a tuple in internal (binary) form. * * This is largely same as printtup,except we don't use the typout func. * */ static void printtup_internal(HeapTuple tuple, TupleDesc typeinfo, DestReceiver *self) The hard part will be agreeing on the actual data format(s), but this can be postponed by having this implementation where people can experiment. After looking at the code again, it seems that we must have already solved (most) alignment issues in printtup, so the task is just agreeing on types' on-wire representations. I just can't imagine adding anything like that in a minor release. In fact, I most would object to adding it in a minor release because we don't add features in a minor release. Now, if you want it kept because you may want to work in that area, we can surely do that. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [COMMITTERS] pgsql/ onfig/docbook.m4 oc/src/sgml/features.sgml
Log message: This fixes 2 inaccuracies in the recently added SQL99 feature list docs. UNIQUE and DISTINCT predicates are both listed as implemented -- AFAIK, neither is. DISTINCT was implemented a couple of weeks ago. I'll change the docs again... - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] bit type external representation
SQL9x defines bit string constants with a format like B'101010' and X'ABCD' for binary and hexadecimal representations. But at the moment we don't explicitly handle both of these cases as bit strings; the hex version is converted to decimal in the scanner (*really* early in the parsing stage) and then handled as an integer. It looks like our current bit string type support looks for a B or X embedded in the actual input string, rather than outside the quote as in the standard. I'd like to have more support for the SQL9x syntax, which requires a little more invasive modification of at least the scanner and parser. I have a couple of questions: 1) the SQL standard says what hex values should be translated to in binary, which implies that all values may be *output* in binary format. Should we do this, or should we preserve the info on what units were used for input in the internal storage? Anyone interpret the standard differently from this?? 2) we would need to be able to determine the format style when a string is output to be able to reconstruct the SQL shorthand representation (if preserving binary or hex is to be done). So a column or value should have a corresponding is_hex() function call. Any other suggestions?? - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] bit type external representation
for binary and hexadecimal representations. But at the moment we don't explicitly handle both of these cases as bit strings; the hex version is converted to decimal in the scanner (*really* early in the parsing stage) and then handled as an integer. It looks like our current bit string type support looks for a B or X embedded in the actual input string, rather than outside the quote as in the standard. I should point out that this is probably for historical reasons; I'd implemented the hex to decimal conversion way before we had bit string support, and we didn't consolidate those features when bit strings came along. - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bit type external representation
for binary and hexadecimal representations. But at the moment we don't
explicitly handle both of these cases as bit strings; the hex version is
converted to decimal in the scanner (*really* early in the parsing
stage) and then handled as an integer.
It looks like our current bit string type support looks for a B or X
embedded in the actual input string, rather than outside the quote as in
the standard.
Postgres supports both:
test=# create table test (a bit(3));
CREATE
test=# insert into test values (B'101');
INSERT 3431020 1
test=# insert into test values (b'101');
INSERT 3431021 1
test=# insert into test values ('B101');
INSERT 3431022 1
test=# insert into test values ('b101');
INSERT 3431023 1
test=# select * from test;
a
-
101
101
101
101
(4 rows)
In fact, some of our apps actually _rely_ on the old 'b101' syntax...
Although these could be changed with some effort...
Chris
---(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] [SQL] line datatype
OK, I have added comments to \dT and SGML docs to mention that 'line' is not implemented. This should help future folks. It would be nice to get the line type working 100%. Thomas says the problem is input/output format. I don't completely understand. --- Tim Hart wrote: Probably the most succinct explanation would be to copy paste from the terminal... tjhart= create table a_line( foo line ); CREATE tjhart= insert into a_line ( foo ) values( '(0,0), (1,1)' ); ERROR: line not yet implemented tjhart= select version(); version - PostgreSQL 7.2.1 on powerpc-apple-darwin5.3, compiled by GCC 2.95.2 (1 row) The documentation (datatype-geometric.html) indicates both a 'line' type and an 'lseg' type in the summary table at the top of the page. The same code above using the type 'lseg' in place of 'line' works just fine. Why can I create a table with a column of type 'line' if I can't insert into it? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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] [PATCHES] CLUSTER not lose indexes
Peter Eisentraut [EMAIL PROTECTED] writes: It would be a lot clearer if relfilenode were replaced by an integer version, starting at 0, and the heap files were named OID_VERSION. The reason to not do that is that the bufmgr and levels below would now need to pass around three numbers, not two, to identify physical files. We already beat this topic to death a year ago, I'm not eager to re-open it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I agree that a wrapper function is probably an appropriate solution, but only some of the calls of SearchSysCache should use it. What like add another parameter to SearchSysCache*? Definitely *not*; I don't want to kluge up every call to SearchSysCache with a feature that's only relevant to a small number of them. Another question: How do I fill out the ObjectAddress when trying to drop related objects? A column would be classId = RelOid_pg_class, objectId = OID of relation, objectSubId = column's attnum. BTW, it occurred to me recently that most of the column-specific AlterTable operations will happily try to alter system columns (eg, OID). In most cases this makes no sense and should be forbidden. It definitely makes no sense for DROP COLUMN... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: I agree that a wrapper function is probably an appropriate solution, but only some of the calls of SearchSysCache should use it. What like add another parameter to SearchSysCache*? Definitely *not*; I don't want to kluge up every call to SearchSysCache with a feature that's only relevant to a small number of them. Uh, then what? The only idea I had was to set a static boolean variable in syscache.c that controls whether droppped columns are returned, and have a enable/disable functions that can turn it on/off. The only problem is that an elog inside a syscache lookup would leave that value set. My only other idea is to make a syscache that is like ATTNAME except that it doesn't return a dropped column. I could probably code that up if you wish. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DROP COLUMN
Uh, then what? The only idea I had was to set a static boolean variable in syscache.c that controls whether droppped columns are returned, and have a enable/disable functions that can turn it on/off. The only problem is that an elog inside a syscache lookup would leave that value set. My only other idea is to make a syscache that is like ATTNAME except that it doesn't return a dropped column. I could probably code that up if you wish. That'd be cool. I guess the thing is that either way, I will need to manually change every single instance where a dropped column should be avoided. So, really there's not much difference between me changing the SysCache search to use ATTNAMEUNDROPPED or whatever, or just checking the attisdropped field of the tuple in the same way that you must always check that attnum 0. In fact, looking at it logically...if all the commands currently are required to check that they're not modifiying a system column, then why not add the requirement that they must also not modify dropped columns? I can do a careful doc search and try to make sure I've touched everything... Chris ---(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] DROP COLUMN
Christopher Kings-Lynne wrote: Uh, then what? The only idea I had was to set a static boolean variable in syscache.c that controls whether droppped columns are returned, and have a enable/disable functions that can turn it on/off. The only problem is that an elog inside a syscache lookup would leave that value set. My only other idea is to make a syscache that is like ATTNAME except that it doesn't return a dropped column. I could probably code that up if you wish. That'd be cool. I guess the thing is that either way, I will need to manually change every single instance where a dropped column should be avoided. So, really there's not much difference between me changing the SysCache search to use ATTNAMEUNDROPPED or whatever, or just checking the attisdropped field of the tuple in the same way that you must always check that attnum 0. In fact, looking at it logically...if all the commands currently are required to check that they're not modifiying a system column, then why not add the requirement that they must also not modify dropped columns? I can do a careful doc search and try to make sure I've touched everything... Makes sense. Of course, we could make a syscache that didn't return system columns either. Actually, the original argument for negative attno's for dropped columns was exactly for this case, that the system column check would catch dropped columns too, but it causes other problems that are harder to fix so we _dropped_ the idea. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Definitely *not*; I don't want to kluge up every call to SearchSysCache with a feature that's only relevant to a small number of them. Uh, then what? Then we make a wrapper function. Something like GetUndeletedColumnByName(relid,attname) replaces SearchSysCache(ATTNAME,...) in those places where you don't want to see deleted columns. It'd return NULL if it finds a column tuple but sees it's deleted. GetUndeletedColumnByNum(relid,attnum) replaces SearchSysCache(ATTNUM,...) similarly. My only other idea is to make a syscache that is like ATTNAME except that it doesn't return a dropped column. That would mean duplicate storage of tuples inside the catcache... 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] DROP COLUMN
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Definitely *not*; I don't want to kluge up every call to SearchSysCache with a feature that's only relevant to a small number of them. Uh, then what? Then we make a wrapper function. Something like GetUndeletedColumnByName(relid,attname) replaces SearchSysCache(ATTNAME,...) in those places where you don't want to see deleted columns. It'd return NULL if it finds a column tuple but sees it's deleted. GetUndeletedColumnByNum(relid,attnum) replaces SearchSysCache(ATTNUM,...) similarly. Good idea. My only other idea is to make a syscache that is like ATTNAME except that it doesn't return a dropped column. That would mean duplicate storage of tuples inside the catcache... No, I was thinking of something that did the normal ATTNAME lookup in the syscache code, then returned NULL on dropped columns; similar to your idea but done inside the syscache code rather than in a separate function. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN
Actually, the original argument for negative attno's for dropped columns was exactly for this case, that the system column check would catch dropped columns too, but it causes other problems that are harder to fix so we _dropped_ the idea. Well, negative attnums are a good idea and yes, you sort of avoid all these problems. However, the backend is _full_ of stuff like this: if (attnum 0) elog(ERROR, Cannot footle system attribute.); But the problem is that we'd have to change all of them anyway in a negative attnum implementation, since they're not system attributes, they're dropped columns. But let's not start another thread about this!! Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP COLUMN
In fact, looking at it logically...if all the commands currently are required to check that they're not modifiying a system column, then why not add the requirement that they must also not modify dropped columns? I can do a careful doc search and try to make sure I've touched everything... Makes sense. Of course, we could make a syscache that didn't return system columns either. Actually - are you certain that every command uses a SearchSysCache and not some other weirdness? If we have to do the odd exception, then maybe we should do them all as 'exceptions'? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
Christopher Kings-Lynne wrote: In fact, looking at it logically...if all the commands currently are required to check that they're not modifiying a system column, then why not add the requirement that they must also not modify dropped columns? I can do a careful doc search and try to make sure I've touched everything... Makes sense. Of course, we could make a syscache that didn't return system columns either. Actually - are you certain that every command uses a SearchSysCache and not some other weirdness? If we have to do the odd exception, then maybe we should do them all as 'exceptions'? I actually don't know. I know all the table name lookups do use syscache or temp tables wouldn't have worked. ;-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DROP COLUMN
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Actually - are you certain that every command uses a SearchSysCache and not some other weirdness? They probably don't. You'll have to look closely at places that use the TupleDesc from a relcache entry. 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] pg_views.definition
Hi, Would it be possible to add a new attribute to pg_views that stores the original view definition, as entered via SQL? This would make the lives of those of us who make admin interfaces a lot easier... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Future of src/utils
Peter Eisentraut wrote: Bruce Momjian writes: However, over time, this distinction has broken down and we have a number of backend/port stuff used in other binaries. I propose moving the src/utils remaining items into src/backend/port, and removing the src/utils directory. I propose the reverse operation. The following patch moves dllinit.c and strdup.c into backend/port, and removes the src/utils directory, for the time being. It also cleans up dllinit so it has its own variable to point to the file path rather than having it hard-coded in all the makefiles. When we decide to move everything to src/utils, it will be all ready. -- 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: configure.in === RCS file: /cvsroot/pgsql/configure.in,v retrieving revision 1.189 diff -c -r1.189 configure.in *** configure.in15 Jul 2002 22:41:45 - 1.189 --- configure.in16 Jul 2002 05:41:22 - *** *** 916,922 AC_SUBST(INET_ATON) AC_CHECK_FUNCS(strerror, [], STRERROR='$(top_builddir)/src/backend/port/strerror.o') AC_SUBST(STRERROR) ! AC_CHECK_FUNCS(strdup, [], STRDUP='$(top_builddir)/src/utils/strdup.o') AC_SUBST(STRDUP) AC_CHECK_FUNCS(strtol, [], STRTOL='$(top_builddir)/src/backend/port/strtol.o') AC_SUBST(STRTOL) --- 916,922 AC_SUBST(INET_ATON) AC_CHECK_FUNCS(strerror, [], STRERROR='$(top_builddir)/src/backend/port/strerror.o') AC_SUBST(STRERROR) ! AC_CHECK_FUNCS(strdup, [], STRDUP='$(top_builddir)/src/backend/port/strdup.o') AC_SUBST(STRDUP) AC_CHECK_FUNCS(strtol, [], STRTOL='$(top_builddir)/src/backend/port/strtol.o') AC_SUBST(STRTOL) *** *** 924,929 --- 924,936 AC_SUBST(STRTOUL) AC_CHECK_FUNCS(strcasecmp, [], STRCASECMP='$(top_builddir)/src/backend/port/strcasecmp.o') AC_SUBST(STRCASECMP) + + # Set path of dllinit.c for cygwin + DLLINIT= + case $host_os in + cygwin*) DLLINIT='$(top_builddir)/src/backend/port/dllinit.o' ;; + esac + AC_SUBST(DLLINIT) # On HPUX 9, rint() is not in regular libm.a but in /lib/pa1.1/libm.a; # this hackery with HPUXMATHLIB allows us to cope. Index: src/Makefile.global.in === RCS file: /cvsroot/pgsql/src/Makefile.global.in,v retrieving revision 1.148 diff -c -r1.148 Makefile.global.in *** src/Makefile.global.in 28 May 2002 16:57:53 - 1.148 --- src/Makefile.global.in 16 Jul 2002 05:41:23 - *** *** 359,364 --- 359,365 STRERROR= @STRERROR@ STRTOL = @STRTOL@ STRTOUL = @STRTOUL@ + DLLINIT = @DLLINIT@ TAS = @TAS@ Index: src/Makefile.shlib === RCS file: /cvsroot/pgsql/src/Makefile.shlib,v retrieving revision 1.58 diff -c -r1.58 Makefile.shlib *** src/Makefile.shlib 24 May 2002 18:10:17 - 1.58 --- src/Makefile.shlib 16 Jul 2002 05:41:23 - *** *** 327,339 else # PORTNAME == win # WIN case ! $(shlib) lib$(NAME).a: $(OBJS) $(top_builddir)/src/utils/dllinit.o $(DLLTOOL) --export-all --output-def $(NAME).def $(OBJS) ! $(DLLWRAP) -o $(shlib) --dllname $(shlib) --def $(NAME).def $(OBJS) $(top_builddir)/src/utils/dllinit.o $(DLLINIT) $(DLLLIBS) $(SHLIB_LINK) $(DLLTOOL) --dllname $(shlib) --def $(NAME).def --output-lib lib$(NAME).a ! $(top_builddir)/src/utils/dllinit.o: $(top_srcdir)/src/utils/dllinit.c ! $(MAKE) -C $(top_builddir)/src/utils dllinit.o endif # PORTNAME == win --- 327,339 else # PORTNAME == win # WIN case ! $(shlib) lib$(NAME).a: $(OBJS) $(DLLINIT) $(DLLTOOL) --export-all --output-def $(NAME).def $(OBJS) ! $(DLLWRAP) -o $(shlib) --dllname $(shlib) --def $(NAME).def $(OBJS) $(DLLINIT) $(DLLLIBS) $(SHLIB_LINK) $(DLLTOOL) --dllname $(shlib) --def $(NAME).def --output-lib lib$(NAME).a ! $(DLLINIT): ! $(MAKE) -C $(@D) $(@F) endif # PORTNAME == win Index: src/backend/Makefile === RCS file: /cvsroot/pgsql/src/backend/Makefile,v retrieving revision 1.79 diff -c -r1.79 Makefile *** src/backend/Makefile22 May 2002 21:46:40 - 1.79 --- src/backend/Makefile16 Jul 2002 05:41:24 - *** *** 43,49 # No points for style here. How about encapsulating some of these # commands into variables? ! postgres: $(OBJS) $(top_builddir)/src/utils/dllinit.o postgres.def libpostgres.a dlltool --dllname $@$(X) --output-exp $@.exp --def postgres.def gcc $(LDFLAGS) -g -o $@$(X) -Wl,--base-file,$@.base $@.exp $(OBJS) $(DLLLIBS) dlltool --dllname $@$(X)
Re: [HACKERS] pg_views.definition
Christopher Kings-Lynne wrote: Hi, Would it be possible to add a new attribute to pg_views that stores the original view definition, as entered via SQL? This would make the lives of those of us who make admin interfaces a lot easier... We actually reverse it on the fly: test= \d xx View xx Column | Type | Modifiers -+--+--- relname | name | View definition: SELECT pg_class.relname FROM pg_class; -- 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])
Re: [HACKERS] BlockNumber fixes
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I did some research on this and generated the following patch. I didn't find much in the way of problems except two vacuum.c fields that should probably be BlockNumber. freespace.c also has a numPages field in FSMRelation that is int. Should that be BlockNumber? Not necessary, since the freespace map will never be large enough to overflow a signed int (it wouldn't fit in the address space if it were). I think that your changes in vacuum.c are probably unnecessary for the same reason. I am generally wary of changing values from signed to unsigned without close analysis of how they are used --- did you look at *every* comparison involving these fields? How about arithmetic that might compute a negative result? The only computation I saw was: vacuumed_pages = vacuum_pages-num_pages - vacuum_pages-empty_end_pages; vacuumed_pages is signed, the others are unsigned. However, we print these values as %u so there is a certain confusion there. If you say it isn't a problem here, I will just mark the item as done and that we are handling the block numbers correctly. The only other unusual case I saw was tid outputing block number as %d and not %u. Is that OK? sprintf(buf, (%d,%d), (int) blockNumber, (int) offsetNumber); tidin uses atoi: blockNumber = (BlockNumber) atoi(coord[0]); so at least it is consistent. ;-) Doesn't seem right, however. Also, pg_class.relpages is an int. We don't have unsigned int columns. -- 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://archives.postgresql.org
Re: [HACKERS] Unused system table columns
Rod Taylor [EMAIL PROTECTED] writes: For all intent and purpose, pg_index.indisprimary can be added to that list. Can't make a primary key without a pg_constraint entry. I disagree. For one thing, there are clients that look at that column. There's no percentage in breaking them to gain zero (and it will be zero, because of alignment considerations...) indisclustered is currently pretty useless, but may become less so if CLUSTER gets upgraded to usefulness, so I'm not in favor of deleting that either. No strong attachment to the other stuff mentioned so far. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] fmtId() and pg_dump
Interesting idea. Not sure how you are going to do that since appendPQExpBuffer uses vsnprintf. Would you spin through the format string and modify the pointers sent to vsnprintf? Seems like a lot of work. FYI, the 7.2 code had fmtId called pretty messed up in certain places but I think I fixed them all. --- Neil Conway wrote: The fmtId() function used in pg_dump for optional quoting identifiers has bothered me for a while now. The API is confusing: the returned value needs to be used before fmtId() is called again, because the buffer the return value points to is re-used for each call of fmtId(). That leads to bugs for those unaware of this requirement, and clumsy code for those that are -- for example (pg_dump.c:2911) appendPQExpBuffer(delq, DROP TYPE %s., fmtId(tinfo-typnamespace-nspname, force_quotes)); appendPQExpBuffer(delq, %s;\n, fmtId(tinfo-typname, force_quotes)); Should really only be 1 line of code. Similar ugliness occurs in many places (e.g. several lines down, there is a section of 4 calls to appendPQExpBuffer() that could be condensed down to 1, if not for fmtId() ). Lastly, it has a tendancy to produce memory leaks -- for example, convertRegProcReference() in pg_dump.c will leak memory when used with PostgreSQL = 7.3. When I mentioned this to Tom Lane, he said that he didn't see a way to fix it without convoluting the code, and suggested I bring it up on -hackers. My suggestion is: since fmtId() is almost always used with appendPQExpBuffer(), we should add a wrapper function to pg_dump that accepts an extra escape sequence (%S, or %i, perhaps), which would properly quote the input string before passing it to appendPQExpBuffer(). That should ensure that there won't be any leaks from adding quotes to identifiers, but also allow us to avoid playing games with static buffers, like fmtId() does now. Any comments? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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] Unused system table columns
Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: For all intent and purpose, pg_index.indisprimary can be added to that list. Can't make a primary key without a pg_constraint entry. I disagree. For one thing, there are clients that look at that column. There's no percentage in breaking them to gain zero (and it will be zero, because of alignment considerations...) Yes, pgaccess uses it, as I remember. Would be nice if it was accurate. indisclustered is currently pretty useless, but may become less so if CLUSTER gets upgraded to usefulness, so I'm not in favor of deleting that either. Yea, I can see that being useful some day. -- 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://archives.postgresql.org
Re: [HACKERS] Unused system table columns
Hannu Krosing [EMAIL PROTECTED] writes: We can always re-add the columns them. But would it not be nice if we could add uniform binary protocol without requiring initdb ? That won't happen, because the existing contents of those columns are completely useless for a binary-protocol feature. If we do ever add such a feature, we'd be better off adding new columns with a different name, just to avoid confusion over what's supposed to be there. (For example: extant pg_dump scripts for user-defined types will try to load wrong values into those columns if given a chance. We *must* use new names for those slots in CREATE TYPE to avoid that pitfall, and so we might as well change the system column name too.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Unused system table columns
I disagree. For one thing, there are clients that look at that column. There's no percentage in breaking them to gain zero (and it will be zero, because of alignment considerations...) Yes, pgaccess uses it, as I remember. Would be nice if it was accurate. Not to mention phpPgAdmin, psql, pg_dump, TOra, pgadmin, etc. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
