Re: [HACKERS] psql and readline
On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Hi, Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Ian Barwick [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])
[HACKERS] Is the 7.3.1 geometry regression test supposed to pass perfectlyon Solaris 8 x86?
Hi guys, Just compiled PG 7.3.1 on Solaris 8 x86, and it failed the GEOMETRY regression test with one of those 15th decimal place is one digit different from expected types of errors. Nothing critical, but not sure if we're trying to have the correct results already accounted for, for Solaris 8 x86. This is the regression.diff in case it's useful: *** bash-2.03$ more /install/postgresql-7.3.1/src/test/regress/regression.diffs *** ./expected/geometry-solaris-i386-pc.out Fri Mar 23 01:43:19 2001 --- ./results/geometry.out Wed Jan 8 21:27:49 2003 *** *** 127,133 | (-5,-12) | [(10,-10),(-3,-4)]| (-1.60487804878049,-4.64390243902439) | (10,10)| [(10,-10),(-3,-4)]| (2.39024390243902,-6.48780487804878) | (0,0) | [(-100,200),(30,-40)] | (0.0028402365895872,15.384614860264) ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140473) | (-3,4) | [(-100,200),(30,-40)] | (-2.99789812267519,15.3851688427303) | (5.1,34.5) | [(-100,200),(30,-40)] | (5.09647083221496,15.3836744976925) | (-5,-12) | [(-100,200),(30,-40)] | (-4.99494420845634,15.3855375281616) --- 127,133 | (-5,-12) | [(10,-10),(-3,-4)]| (-1.60487804878049,-4.64390243902439) | (10,10)| [(10,-10),(-3,-4)]| (2.39024390243902,-6.48780487804878) | (0,0) | [(-100,200),(30,-40)] | (0.0028402365895872,15.384614860264) ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140472) | (-3,4) | [(-100,200),(30,-40)] | (-2.99789812267519,15.3851688427303) | (5.1,34.5) | [(-100,200),(30,-40)] | (5.09647083221496,15.3836744976925) | (-5,-12) | [(-100,200),(30,-40)] | (-4.99494420845634,15.3855375281616) *** *** 152,158 | (2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964) | (71.7106781186548,72.7106781186548),(-69.7106781186548,-68.7106781186548) | (4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932738) ! | (3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559642) | (107.071067811865,207.071067811865),(92.9289321881345,192.928932188135) | (170.710678118655,70.7106781186548),(29.2893218813452,-70.7106781186548) (6 rows) --- 152,158 | (2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964) | (71.7106781186548,72.7106781186548),(-69.7106781186548,-68.7106781186548) | (4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932738) ! | (3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559643) | (107.071067811865,207.071067811865),(92.9289321881345,192.928932188135) | (170.710678118655,70.7106781186548),(29.2893218813452,-70.7106781186548) (6 rows) *** *** 504,510 ORDER BY distance, circle, point using ; twentyfour | circle | point| distance +++--- ! | (100,0),100 | (5.1,34.5) | 0.976531926977965 | (1,2),3 | (-3,4) | 1.47213595499958 | (0,0),3 | (-3,4) | 2 | (100,0),100 | (-3,4) | 3.07764064044151 --- 504,510 ORDER BY distance, circle, point using ; twentyfour | circle | point| distance +++--- ! | (100,0),100 | (5.1,34.5) | 0.976531926977964 | (1,2),3 | (-3,4) | 1.47213595499958 | (0,0),3 | (-3,4) | 2 | (100,0),100 | (-3,4) | 3.07764064044151 *** *** 519,525 | (0,0),3 | (10,10)| 11.142135623731 | (1,3),5 | (-5,-12) | 11.1554944214035 | (1,2),3 | (-5,-12) | 12.2315462117278 ! | (1,3),5 | (5.1,34.5) | 26.7657047773223 | (1,2),3 | (5.1,34.5) | 29.757594539282 | (0,0),3 | (5.1,34.5) | 31.8749193547455 | (100,200),10 | (5.1,34.5) | 180.778038568384 --- 519,525 | (0,0),3 | (10,10)| 11.142135623731 | (1,3),5 | (-5,-12) | 11.1554944214035 | (1,2),3 | (-5,-12) | 12.2315462117278 ! | (1,3),5 | (5.1,34.5) | 26.7657047773224 | (1,2),3 | (5.1,34.5) | 29.757594539282 | (0,0),3 | (5.1,34.5) | 31.8749193547455 | (100,200),10 | (5.1,34.5) | 180.778038568384 == bash-2.03$ *** CFLAGS and other relevant environment variables at time of
Re: [HACKERS] MOVE LAST: why?
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: FETCH LAST should return the last one row. That's not clear to me. Generally, I would think the cursor should remain positioned on whatever row is returned, but the spec clearly says that the final cursor position after FETCH LAST is *after* the last row. In SQL99 the spec you referred to seems the ii) of b) which begins with the word *Otherwise*. I see the following before it. a) If K is greater than 0 (zero) and not greater than N, then CR is positioned on the K-th row of Tt and the corresponding row of T. That row becomes the current row of CR. Then I'm also suspicious if MOVE LAST should mean MOVE ALL. FETCH RELATIVE m should return a row after skipping m rows if we follow the SQL standard and so the current implementation of FETCH RELATIVE is broken. No objection to that here. Are you volunteering to make it do that? I'm suspicios if we should implement scrollable cursors with the combination of the current MOVE and FETCH implemen- tation. For example the backwards FETCH operation for group nodes isn't implemented properly yet(maybe). Should we fix it or take another way ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MOVE LAST: why?
FETCH LAST should return the last one row. FETCH RELATIVE m should return a row after skipping m rows if we follow the SQL standard and so the current implementation of FETCH RELATIVE is broken. Yes, the syntax could probably be FETCH [n] RELATIVE m to keep the functionality to fetch n rows at once and not only one after skipping m rows. Andreas ---(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] psql and readline
On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Hi, Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( -- Fduch M. Pravking ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
On Wednesday 08 January 2003 13:02, Alexander M. Pravking wrote: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Hi, Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Yes, but the query will remain in the psql query buffer until a different SQL query (i.e. not a slash command) is executed. Until then you can reedit and / or reexecute the query (with \g) as long as you like. Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
On Wed, 8 Jan 2003, Christopher Kings-Lynne wrote: Hi, Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... When you say multiline do you mean this: template1=$ select * from template1-$ abc a template1-$ where a.id=1; or a situation where the query text exceeds the terminal width and wraps to the next line? If the latter, see if horizontal-scroll-mode is set to off in your ~/.inputrc. If the former, that sounds kind of elaborate and to wrong way to do things. Chris Gavin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] redo error?
On Tue, 2003-01-07 at 22:58, Tom Lane wrote: It also logged that it was killed with signal 9, although I didn't kill it! Is there something weird going on here? Is this Linux? The Linux kernel seems to think that killing randomly-chosen processes with SIGKILL is an appropriate response to running out of memory. I cannot offhand think of a more brain-dead behavior in any OS living or dead, but that's what it does. Just FYI, I believe the 2.6.x series of kernels will rectify this situation. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] python interface
On Saturday 04 January 2003 19:58, Marc G. Fournier wrote:
Let me know how it goes, and what the project is ... that way we can move
the current CVS over so that we don't lose the extensive logging history
Hmm. I didn't think that it was suggested to move the repository again. I
thought I was just going to add a pointer to the PyGreSQL page but leave the
code where it was. If we move it won't it make it harder to add it with just
a config option like we do now?
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] UTF-8 encoding question regarding PhpPgAdmin
On Tue, 2003-01-07 at 21:59, Peter Eisentraut wrote: - Some letters, like the euro sign, do not belong to Latin1. Example: let's say we have a Latin1 database and use SET CLIENT_ENCODING = 'Unicode'. If I input a euro sign, does it get rejected by PostgreSQL? Currently, it gives you a warning and ignores the character. Not sure that is ideal. (Yes, I should try this myself...) Ignored as in 'passed through unchanged'; or ignored as in 'removed from the string'? cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] psql and readline
Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... When you say multiline do you mean this: template1=$ select * from template1-$ abc a template1-$ where a.id=1; Yes. Basically, the classic example is when I copy and paste large queries or DDL from my SQL files in CVS. It's a real pain. 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: [GENERAL] [HACKERS] I feel the need for speed. What am I doing
No analyze for 7.1.3. Just ran vacuum a few minutes before the query. No boost at all. Even with SET enable_seqscan = 0 it still does a table scan. Dann, I can attest to 7.2 having a much better planner and performance than 7.1 did. Can you upgrade? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sync()
Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: What we really need is something better than sync(), viz flush all dirty buffers to disk *and* wait till they're written. But sync() and sleep for awhile is the closest portable approximation. Are you saying that fsync() might not wait untill the IO completes? No, I said that sync() might not. Read the man pages. HPUX's man page for sync(2) says sync() causes all information in memory that should be on disk to be written out. ... The writing, although scheduled, is not necessarily complete upon return from sync. Yep, BSD/OS says: BUGS Sync() may return before the buffers are completely flushed. At least they classify it as a bug. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Is the 7.3.1 geometry regression test supposed to pass perfectly on Solaris 8 x86?
Justin Clift [EMAIL PROTECTED] writes: Just compiled PG 7.3.1 on Solaris 8 x86, and it failed the GEOMETRY regression test with one of those 15th decimal place is one digit different from expected types of errors. I don't think we really care anymore about that; CVS tip has a modified geometry test that suppresses low-order-digit differences. If you care to try CVS tip on that machine, it'd be useful to know if it passes cleanly. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] python interface
D'Arcy J.M. Cain wrote: On Saturday 04 January 2003 19:58, Marc G. Fournier wrote: Let me know how it goes, and what the project is ... that way we can move the current CVS over so that we don't lose the extensive logging history Hmm. I didn't think that it was suggested to move the repository again. I thought I was just going to add a pointer to the PyGreSQL page but leave the code where it was. If we move it won't it make it harder to add it with just a config option like we do now? Yes, it will make it harder, but we can release independently, and others may get more involved in it. We have moved the CVS for most of the interfaces, and they are doing fine on gborg. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Read-only transactions
Tom Lane writes:
case T_VacuumStmt:
/* No XactReadOnly check since this logically changes no data */
vacuum((VacuumStmt *) parsetree);
break;
Then it'll be hard to miss the need to think about this when adding a
new statement.
Well, I had one big check at the top so it doesn't have to be spread out
so much:
static void
check_xact_readonly(Node *parsetree)
{
if (!XactReadOnly)
return;
switch (nodeTag(parsetree))
{
case T_AlterDatabaseSetStmt:
case T_AlterDomainStmt:
case T_AlterGroupStmt:
[...]
case T_DropUserStmt:
case T_GrantStmt:
case T_TruncateStmt:
elog(ERROR, transaction is read-only);
break;
}
}
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong?
-Original Message- From: scott.marlowe [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 6:30 AM To: Dann Corbit Cc: johnn; [EMAIL PROTECTED] Subject: Re: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong? No analyze for 7.1.3. Just ran vacuum a few minutes before the query. No boost at all. Even with SET enable_seqscan = 0 it still does a table scan. Dann, I can attest to 7.2 having a much better planner and performance than 7.1 did. Can you upgrade? No, not yet. I am using a native Win32 port that we did ourselves. Once the PostgreSQL team completes the Win32 port, I will abandon this code base and use that code. This is for a commercial enterprise and Cygwin is out of the question because of the distribution problems. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
Alexander M. Pravking [EMAIL PROTECTED] writes: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Hm, so it does. It seems like the edited query should go into history, at least when you execute it. Peter, is this fixable? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
Tom Lane wrote: Alexander M. Pravking [EMAIL PROTECTED] writes: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Hm, so it does. It seems like the edited query should go into history, at least when you execute it. Peter, is this fixable? Wow, that would be a nifty trick, though they really did type \e and not the query the pulled in from the editor. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 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] psql and readline
On 8 Jan 2003 at 12:28, Bruce Momjian wrote: Tom Lane wrote: Alexander M. Pravking [EMAIL PROTECTED] writes: On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote: On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote: Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Not that I know of, but you can use \e to edit the query in your favourite editor. Sure. But \e puts \e into history, instead of the query itself :( Hm, so it does. It seems like the edited query should go into history, at least when you execute it. Peter, is this fixable? Wow, that would be a nifty trick, though they really did type \e and not the query the pulled in from the editor. What about those of us who want to use \e repeatedly? Will that be in the history buffer? -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] Have people taken a look at pgdiff yet?
On Tuesday 07 January 2003 18:36, Steve Crawford wrote: I'm busy trying to set up AOLserver to access PostgreSQL. Can you offer any advice on what driver to use (docs aren't entirely clear on the virtues of the internal PostgreSQL driver vs. the ARSdigita driver and it looks like the ARSdigita is being merged into the AOLserver code but that's in a beta state - a bit of a headache for an AOLserver newbie). The officially sanctioned latest driver version in 3.5, found on the SourceForge AOLserver file download page. OpenACS is built on top of AOLserver, it's true; they are still separate projects, even though the driver has hooks in it for OpenACS use. The OpenACS sample tcl config shows how to load the nspostgres driver (even though it may call it 'postgres' instead). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] UTF-8 encoding question regarding PhpPgAdmin development
Jean-Michel POURE writes: Finally, when you display East Asian characters you will have a font problem because the Chinese, Japanese, and Korean characters are mapped to the same range in Unicode but you are supposed to use country-specific glyphs. Do you mean that glyph hexaX will display differently in UTF-8 and EUC_JP? If it is really the case, we cannot use UTF-8. Well, it's not completely different, but customized to the language. The Chinese, Japanese, and Korean ideographs are really the same historically but are displayed slightly differently. If you use a country-specific character set you probably also get a country-specific font with it, but if you map it to Unicode then you will get whatever the default look is on your computer. This is actually not so bad because as I understand it, for example, a Japanese book that quotes Chinese text uses the Japanese-look ideographs for the Chinese portions as well. But a database administration tool is not a Japanese book, so you need to judge it. -- 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] UTF-8 encoding question regarding PhpPgAdmin
- Some letters, like the euro sign, do not belong to Latin1. Example: let's say we have a Latin1 database and use SET CLIENT_ENCODING = 'Unicode'. If I input a euro sign, does it get rejected by PostgreSQL? Currently, it gives you a warning and ignores the character. Not sure that is ideal. (Yes, I should try this myself...) Ignored as in 'passed through unchanged'; or ignored as in 'removed from the string'? removed from the string. BTW, if I remember correctly, the euro sign is supported in ISO-8859-16, not in ISO-8859-1. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MOVE LAST: why?
Hiroshi Inoue [EMAIL PROTECTED] writes: I'm suspicios if we should implement scrollable cursors with the combination of the current MOVE and FETCH implemen- tation. For example the backwards FETCH operation for group nodes isn't implemented properly yet(maybe). Yeah, backwards scan is not implemented for quite a large number of plan node types :-(. I am not sure that it is practical to fix them all. I have been toying with the notion of making cursors on complex plans safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if the top plan node isn't one that can handle backwards scan. The trouble with this of course is that one of the main things people like to use cursors for is huge result sets, and materializing those is the last thing you want to do :-( regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bug in pg_get_constraintdef (for deferrable constraints)
OK, patch applied to HEAD and 7.3.X. It does suppress options that are already the default: (patch attached) That is: test= CREATE TABLE a1 (x int primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'a1_pkey' for table 'a1' CREATE TABLE test= CREATE TABLE a2 (y int references a1 (x)); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE TABLE dumps out as: ALTER TABLE ONLY a2 ADD CONSTRAINT $1 FOREIGN KEY (y) REFERENCES a1(x) ON UPDATE NO ACTION ON DELETE NO ACTION; However, this: test= create table a1 (x int primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'a1_pkey' for table 'a1' CREATE TABLE test= create table a2 (y int references a1 (x) deferrable initially deferred); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE TABLE dumps out as; ALTER TABLE ONLY a2 ADD CONSTRAINT $1 FOREIGN KEY (y) REFERENCES a1(x) ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED; --- Stephan Szabo wrote: On Wed, 1 Jan 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I see the values being stored on constriant creation, but not being used anywhere: I believe the values that actually get inspected at runtime are the tgdeferrable and tginitdeferred fields in pg_trigger. The columns in pg_constraint are just copies of these. It is not real clear to me whether it should be allowed to alter the deferrability status of a foreign-key constraint --- is that in the spec? The big problem is that while pg_dump's dump_trigger() looks at tginitdeferred and dumps accordingly, pg_get_constraintdef doesn't look at tginitdeferred, and therefore doesn't record the requirement as part of ALTER TABLE ADD CONSTRAINT. pg_get_constraintdef should probably be looking at condeferrable and condeferred in the pg_constraint row it's looking at. Maybe something like the attached. Content-Description: [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/backend/utils/adt/ruleutils.c === RCS file: /cvsroot/pgsql-server/src/backend/utils/adt/ruleutils.c,v retrieving revision 1.129 diff -c -c -r1.129 ruleutils.c *** src/backend/utils/adt/ruleutils.c 14 Dec 2002 00:17:59 - 1.129 --- src/backend/utils/adt/ruleutils.c 8 Jan 2003 22:51:03 - *** *** 688,693 --- 688,698 } appendStringInfo(buf, ON DELETE %s, string); + if (conForm-condeferrable) + appendStringInfo(buf, DEFERRABLE); + if (conForm-condeferred) + appendStringInfo(buf, INITIALLY DEFERRED); + break; } ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] MOVE LAST: why?
I said: Yeah, backwards scan is not implemented for quite a large number of plan node types :-(. I am not sure that it is practical to fix them all. I have been toying with the notion of making cursors on complex plans safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if the top plan node isn't one that can handle backwards scan. I forgot to mention plan B: make use of ReScan. This could work like so: 1. Cursor keeps track of row number (number of rows it's fetched). 2. To scan backwards when top plan type doesn't handle it, rewind all the way with ReScan, then move forward the appropriate number of rows. This would avoid any added overhead in the case where a backwards move is never requested, and it also would support MOVE BACKWARD ALL quite efficiently (much more so than now). On the other hand, it'd really suck if the user asks for backwards scan from a point far into the output. Perhaps we could do something with a hybrid technique: don't materialize the cursor output unless user actually asks for backwards scan. If he does, then create a tuplestore and put the data into it (rescanning the query output to do so), and finally supply the tuples from the tuplestore. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MOVE LAST: why?
Tom Lane wrote: Perhaps we could do something with a hybrid technique: don't materialize the cursor output unless user actually asks for backwards scan. Or we can check the existence of SCROLL keyword which is currently ignored. In the first place SQL standard only allows NEXT fetch unless SCROLL is specified. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(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] MOVE LAST: why?
Tom Lane kirjutas N, 09.01.2003 kell 04:05: I said: Yeah, backwards scan is not implemented for quite a large number of plan node types :-(. I am not sure that it is practical to fix them all. I have been toying with the notion of making cursors on complex plans safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, How much work would it be do the MATERIAL node so that it is calculated at the time of initial forward scan (i.e. FETCH/MOVE) ? if the top plan node isn't one that can handle backwards scan. I forgot to mention plan B: make use of ReScan. This could work like so: 1. Cursor keeps track of row number (number of rows it's fetched). 2. To scan backwards when top plan type doesn't handle it, rewind all the way with ReScan, then move forward the appropriate number of rows. This would avoid any added overhead in the case where a backwards move is never requested, and it also would support MOVE BACKWARD ALL quite efficiently (much more so than now). On the other hand, it'd really suck if the user asks for backwards scan from a point far into the output. Perhaps we could do something with a hybrid technique: don't materialize the cursor output unless user actually asks for backwards scan. If he does, then create a tuplestore and put the data into it (rescanning the query output to do so), and finally supply the tuples from the tuplestore. How hard would it be to save snapshots of scan state at certain places, say at each 1000 tuples, so that a full re-scan is not neccessary ? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] MOVE LAST: why?
Zeugswetter Andreas SB SD wrote: FETCH LAST should return the last one row. FETCH RELATIVE m should return a row after skipping m rows if we follow the SQL standard and so the current implementation of FETCH RELATIVE is broken. Yes, the syntax could probably be FETCH [n] RELATIVE m to keep the functionality to fetch n rows at once and not only one after skipping m rows. What I've thought is FETCH RELATIVE m [n]. Either is OK to me. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about bit.h and bit.c
Files removed. --- Sailesh Krishnamurthy wrote: Tom == Tom Lane [EMAIL PROTECTED] writes: Tom Sailesh Krishnamurthy [EMAIL PROTECTED] writes: Why is it that bit.h is in src/include/utils and bit.c is in src/backend/lib ? Tom Possibly a more interesting question is why haven't we Tom ditched them both ... AFAICT none of the bit.c routines are Tom used anymore. True. I just searched and found the only uses of the bitmask functions (now greatly expanded) in our code :-) -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] ipv6 build error?
Actually, CVS HEAD now builds and compiles quite cleanly on the Alpha. I'm
not sure what you did to fix it? Perhaps it's not compiling in ipv6 at all?
If so, probably doesn't matter.
Anyway, it's all fine now.
Chris
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 9 January 2003 9:16 AM
To: Christopher Kings-Lynne
Cc: Hackers
Subject: Re: [HACKERS] ipv6 build error?
OK, Christopher, how should we deal with this? I don't think defining
_KERNEL is a good idea. The only thing I can think of, if only s6_addr
is standard, is to change:
dst-in.sin_addr.s_addr = src-in6.sin6_addr.s6_addr32[3];
into taking the last 4 array elements of s6_addr and doing a shift of
24/16/8 to get an unsigned int32 value.
--
-
Christopher Kings-Lynne wrote:
Hi Bruce,
I seem to have this:
struct in6_addr {
union {
u_int8_t __u6_addr8[16];
u_int16_t __u6_addr16[8];
u_int32_t __u6_addr32[4];
} __u6_addr;/* 128-bit IP6 address */
};
#define s6_addr __u6_addr.__u6_addr8
#ifdef _KERNEL /*XXX nonstandard*/
#define s6_addr8 __u6_addr.__u6_addr8
#define s6_addr16 __u6_addr.__u6_addr16
#define s6_addr32 __u6_addr.__u6_addr32
#endif
#define INET6_ADDRSTRLEN46
I've attached the full header file.
ifconfig shows IPv6 addresses on the network interfaces, so I
assume I have
ipv6 built. It is a 4.4-stable box with GENERIC kernel. I just rebuilt
from very latest CVS and it still failed.
Chris
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 7 January 2003 12:01 AM
To: Christopher Kings-Lynne
Cc: Hackers
Subject: Re: [HACKERS] ipv6 build error?
Interesting.
I see in BSD/OS /usr/include/netinet6/in6.h:
struct in6_addr {
union {
u_int8_t __u6_addr8[16];
u_int16_t __u6_addr16[8];
u_int32_t __u6_addr32[4];
} __u6_addr;/* 128-bit IP6 address */
};
#define s6_addr __u6_addr.__u6_addr8
#define s6_addr8 __u6_addr.__u6_addr8
#define s6_addr16 __u6_addr.__u6_addr16
#define s6_addr32 __u6_addr.__u6_addr32
and of course the line in ip.c that is causing the problem is:
dst-in.sin_addr.s_addr = src-in6.sin6_addr.s6_addr32[3];
Do you see anything like that? Are you using the newest CVS? (I did
make some CVS adjustments for Tom about 10 hours ago.)
We did pull out IPv6 that was part of an SSL patch in the past because
we didn't support IPv6 anyway. This patch does fully support
IPv6 so we
are going to have to adjust things so configure and the code properly
detect and deal with all the IPv6 implementations out there.
--
-
Christopher Kings-Lynne wrote:
On FreeBSD/Alpha:
gmake[3]: Entering directory
`/home/chriskl/pgsql-head/src/backend/libpq'
gcc -pipe -O -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../..
/src/include -c -o be-fsstubs.o be-fsstubs.c -MMD
gcc -pipe -O -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../..
/src/include -c -o be-secure.o be-secure.c -MMD
gcc -pipe -O -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../..
/src/include -c -o auth.o auth.c -MMD
gcc -pipe -O -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../..
/src/include -c -o crypt.o crypt.c -MMD
gcc -pipe -O -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../..
/src/include -c -o hba.o hba.c -MMD
gcc -pipe -O -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../..
/src/include -c -o ip.o ip.c -MMD
ip.c: In function `convSockAddr6to4':
ip.c:368: structure has no member named `s6_addr32'
gmake[3]: *** [ip.o] Error 1
gmake[3]: Leaving directory
`/home/chriskl/pgsql-head/src/backend/libpq'
gmake[2]: *** [libpq-recursive] Error 2
gmake[2]: Leaving directory `/home/chriskl/pgsql-head/src/backend'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/home/chriskl/pgsql-head/src'
gmake: *** [install] Error 2
I seem to remember seeing this before when we had some ipv6
code that we
decided to remove in the end...
Chris
---(end of
broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square,
Pennsylvania 19073
Re: [HACKERS] ipv6 build error?
Christopher Kings-Lynne wrote: Actually, CVS HEAD now builds and compiles quite cleanly on the Alpha. I'm not sure what you did to fix it? Perhaps it's not compiling in ipv6 at all? If so, probably doesn't matter. Yes, I think it is accurate that it isn't compiling at all. I modified the configure tests to check for sockaddr_in6, and that is more accurate. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MOVE LAST: why?
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: I'm suspicios if we should implement scrollable cursors with the combination of the current MOVE and FETCH implemen- tation. For example the backwards FETCH operation for group nodes isn't implemented properly yet(maybe). Yeah, backwards scan is not implemented for quite a large number of plan node types :-(. I am not sure that it is practical to fix them all. I have been toying with the notion of making cursors on complex plans safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if the top plan node isn't one that can handle backwards scan. The trouble with this of course is that one of the main things people like to use cursors for is huge result sets, and materializing those is the last thing you want to do :-( Honestly I'm not so enthusiastic about scrollable cursors. Even though PostgreSQL provides an efficient scrollable cursor, I would use it little unless it could survive across transactions. Anyway it's too bad that FETCH LAST means FETCH ALL. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
