Re: [PATCHES] Repost: Linking references in documentation
Michael Glaesemann <[EMAIL PROTECTED]> writes: > Below is a patch to provide a few links between the former > administrator's guide and appropriate reference pages. Patch applied, with some additional changes in the same vein. The actual patch I applied is attached. Thanks for the patch. -Neil Index: doc/src/sgml/backup.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/backup.sgml,v retrieving revision 2.35 diff -c -r2.35 backup.sgml *** a/doc/src/sgml/backup.sgml 3 Feb 2004 17:34:02 - 2.35 --- b/doc/src/sgml/backup.sgml 17 Feb 2004 08:49:05 - *** *** 86,94 When your database schema relies on OIDs (for instance as foreign keys) you must instruct pg_dump to dump the OIDs as well. To do this, use the -o command line ! option. Large objects are not dumped by default, either. ! See pg_dump's command reference page if you use ! large objects. --- 86,94 When your database schema relies on OIDs (for instance as foreign keys) you must instruct pg_dump to dump the OIDs as well. To do this, use the -o command line ! option. Large objects are not dumped by default, ! either. See 's reference page if you ! use large objects. *** *** 260,266 pg_dump -Fc dbname > filename ! See the pg_dump and pg_restore reference pages for details. --- 260,267 pg_dump -Fc dbname > filename ! See the and reference pages for details. *** *** 298,305 ! Please familiarize yourself with the ! pg_dump reference page. --- 299,306 ! Please familiarize yourself with the ! reference page. Index: doc/src/sgml/user-manag.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/user-manag.sgml,v retrieving revision 1.24 diff -c -r1.24 user-manag.sgml *** a/doc/src/sgml/user-manag.sgml 29 Nov 2003 19:51:38 - 1.24 --- b/doc/src/sgml/user-manag.sgml 17 Feb 2004 08:55:14 - *** *** 161,168 A user's attributes can be modified after creation with ALTER USER.ALTER USER ! See the reference pages for CREATE USER and ! ALTER USER for details. --- 161,169 A user's attributes can be modified after creation with ALTER USER.ALTER USER ! See the reference pages for the and commands for details. Index: doc/src/sgml/ref/pg_restore.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/pg_restore.sgml,v retrieving revision 1.45 diff -c -r1.45 pg_restore.sgml *** a/doc/src/sgml/ref/pg_restore.sgml 6 Dec 2003 03:00:10 - 1.45 --- b/doc/src/sgml/ref/pg_restore.sgml 17 Feb 2004 08:36:53 - *** *** 110,116 Create the database before restoring into it. (When this option is used, the database named with -d is ! used only to issue the initial CREATE DATABASE command. All data is restored into the database name that appears in the archive.) --- 110,116 Create the database before restoring into it. (When this option is used, the database named with -d is ! used only to issue the initial CREATE DATABASE command. All data is restored into the database name that appears in the archive.) *** *** 454,460 internally executes SQL statements. If you have problems running pg_restore, make sure you are able to select information from the database using, for !example, psql. --- 454,460 internally executes SQL statements. If you have problems running pg_restore, make sure you are able to select information from the database using, for !example, . ---(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: [PATCHES] [pgsql-hackers-win32] win32 setitimer implementation
> Here is a patch that implements setitimer() on win32. With this patch
> applied, deadlock detection and statement_timeout now works.
>
> The file timer.c goes into src/backend/port/win32/.
Minor comments:
* "timer.c" has shmem.c in header
* I'd suggest Asserts on the remaining 2 limitations ("zero" it_interval and
NULL ovalue), on the off chance that some future change to the source
expects them (ie. so we'll find out about it under win32 pretty quickly);
possibly provide defines of ITIMER_VIRT and ITIMER_PROF, for completeness.
Looks good,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em
ailpolicy.html
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] [pgsql-hackers-win32] win32 setitimer implementation
Ok, here's an updated timer.c that fixes these concerns and also adds a
$postgresql$ header to the file.
It also removes the check if value == NULL, since that is now Asserted
instead. And it really should never happen based on the places where
setitimer is used.
The patch stays unchanged, just a new timer.c
//Magnus
>-Original Message-
>From: Claudio Natoli [mailto:[EMAIL PROTECTED]
>Sent: den 17 februari 2004 12:25
>To: Magnus Hagander; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
>Subject: RE: [pgsql-hackers-win32] win32 setitimer implementation
>
>
>
>
>
>> Here is a patch that implements setitimer() on win32. With
>this patch
>> applied, deadlock detection and statement_timeout now works.
>>
>> The file timer.c goes into src/backend/port/win32/.
>
>Minor comments:
>
>* "timer.c" has shmem.c in header
>* I'd suggest Asserts on the remaining 2 limitations ("zero"
>it_interval and NULL ovalue), on the off chance that some
>future change to the source expects them (ie. so we'll find
>out about it under win32 pretty quickly); possibly provide
>defines of ITIMER_VIRT and ITIMER_PROF, for completeness.
>
>Looks good,
>Claudio
>
>---
>Certain disclaimers and policies apply to all email sent from
>Memetrics. For the full text of these disclaimers and policies see
>href="http://www.memetrics.com/emailpolicy.html";>http://www.mem
>etrics.com/em
>ailpolicy.html
>
timer.c
Description: timer.c
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] Doing psql's lexing with flex
I got interested enough in the psql-with-flex problem to go off and solve it. Attached is a working patch, which I'm now debating whether to apply. Comments solicited... The patch removes about 200 lines of very spaghetti-ish code in mainloop.c. However, it adds an 875-line flex source file, which might be thought a bad tradeoff :-(. One bright spot is that about half of that total is a direct copy of the main backend lexer, so it's not really as much new, separately maintainable code as all that. Also, Andrew Dunstan's patch for supporting dollar-quoting would add about 100 lines to mainloop.c, versus only a dozen or so lines in the flex implementation. Once that's taken into account I don't think there is a lot of difference in effective SLOC to maintain. I'm also of the opinion that the new C code in psqlscan.l is much more straightforward than the code removed from mainloop.c, though having just written it, I'm no doubt pretty biased. Bruce was asking about speed. On normal-size queries I cannot measure any difference at all. For testing purposes I made up a file containing a single 750K query (just a "SELECT big-honking-string-constant", with the string literal broken into lines of 75 bytes). The client-side (psql) CPU time to run this file looks about like this on my machine: PGCLIENTENCODING UNICODE SJIS CVS tip 1.571.82 flex implementation 0.932.33 The flex implementation is consistently faster than CVS tip when dealing with backend-compatible encodings (such as UTF-8). It's consistently slower when it has to deal with a non-backend-safe encoding such as SJIS or Big5. But for real-world cases the differential is down in the noise either way. I'm inclined to apply this but I can see where a person not comfortable with flex might feel differently. Opinions? regards, tom lane bin0.bin Description: psql-flex.patch.gz ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Doing psql's lexing with flex
Tom Lane wrote: > I got interested enough in the psql-with-flex problem to go off and > solve it. Attached is a working patch, which I'm now debating whether > to apply. Comments solicited... > > The patch removes about 200 lines of very spaghetti-ish code in > mainloop.c. However, it adds an 875-line flex source file, which > might be thought a bad tradeoff :-(. One bright spot is that about > half of that total is a direct copy of the main backend lexer, so > it's not really as much new, separately maintainable code as all that. > Also, Andrew Dunstan's patch for supporting dollar-quoting would add > about 100 lines to mainloop.c, versus only a dozen or so lines in the > flex implementation. Once that's taken into account I don't think there > is a lot of difference in effective SLOC to maintain. I'm also of the > opinion that the new C code in psqlscan.l is much more straightforward > than the code removed from mainloop.c, though having just written it, > I'm no doubt pretty biased. > > Bruce was asking about speed. On normal-size queries I cannot measure > any difference at all. For testing purposes I made up a file containing > a single 750K query (just a "SELECT big-honking-string-constant", with > the string literal broken into lines of 75 bytes). The client-side > (psql) CPU time to run this file looks about like this on my machine: > > PGCLIENTENCODING > UNICODE SJIS > > CVS tip 1.571.82 > > flex implementation 0.932.33 Looks good. I withdraw my performance concerns. Thanks for testing. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Doing psql's lexing with flex
Tom Lane <[EMAIL PROTECTED]> writes: > I'm inclined to apply this but I can see where a person not comfortable > with flex might feel differently. Opinions? Looks good to me. The psql cleanup is nice, and ISTM that much of the flex code is comments or flex boilerplate anyway, so the actual LOC increase isn't too bad. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Doing psql's lexing with flex
Neil Conway <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> I'm inclined to apply this but I can see where a person not comfortable >> with flex might feel differently. Opinions? > Looks good to me. The psql cleanup is nice, and ISTM that much of the > flex code is comments or flex boilerplate anyway, so the actual LOC > increase isn't too bad. I just realized that something I had planned to look at later is actually an essential step if this is to be applied. I had wanted to see if lexing of backslash command tokens could be folded into the flex lexer as well, but thought I could leave it for later. The case where this doesn't preserve the previous behavior is if the expansion of a psql variable includes both a backslash command and some part of its arguments. As patched, HandleSlashCommand will only look to the original input string and not see the contents of any psql variables (because those are only seen inside the lexer, I'm not physically inserting them into the line buffer as the old code did). Imagine for example \set foo '\c mydb' blah :foo bar The existing code would interpret this as blah \c mydb bar but my patch as it stands would behave very strangely --- the \c command would see bar as its argument and then 'mydb' would be regurgitated after HandleSlashCommand finishes. The existing code is pretty darn inconsistent on this point anyway when you look at it carefully. AFAICS a variable reference is handled quite differently in the arguments of a backslash command than elsewhere; it can't supply general text but only a single option value. The same variable expanded before control reaches HandleSlashCommand is going to look indistinguishable from hand-entered text. If we did translate it into a flex thing the behavior would be different in corner cases like this. Peter, any comments on this? Is the current behavior actually intentional, or did it just fall out of the implementation techniques? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] Crash when calling a pl/pgsql function with no row to pass as an argument
POSTGRESQL BUG REPORT TEMPLATE Your name : Chris Campbell Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : PowerPC G3 Operating System (example: Linux 2.4.18) : Mac OS X 10.3.2 (Darwin 7.2.0) PostgreSQL version (example: PostgreSQL-7.4.1): PostgreSQL-7.4.1 Compiler used (example: gcc 2.95.2) : gcc 3.3 20030304 Please enter a FULL description of your problem: postmaster crashes if it tries to call a pl/plgsql function that requires a table row as an argument, and there is no row produced in the query that can be passed in. There is currently an assertion in the code to guard against this case, but it's not an error case, so it needs to be handled more gracefully than crashing. :) Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- In order to encounter the situation described above, you have to execute a query that calls a pl/pgsql function expecting a table row as an argument, but have the query produce no row that can be passed in. For example, doing a left join between a patient and dentist table where there is no dentist row for a corresponding patient row. And then call a pl/pgsql function, passing in the nonexistent dentist row. CREATE TABLE patient ( patient_id INTEGER, first_name TEXT, last_name TEXT, dentist_id INTEGER ); CREATE TABLE dentist ( dentist_id INTEGER, first_name TEXT, last_name TEXT ); CREATE OR REPLACE FUNCTION full_name(dentist) RETURNS text AS ' DECLARE d ALIAS FOR $1; BEGIN RETURN d.first_name || '' '' || d.last_name; END; ' LANGUAGE 'plpgsql'; -- Note: John Smith has no dentist INSERT INTO patient (patient_id, first_name, last_name) VALUES (1, 'John', 'Smith'); -- Get a list of patient IDs and dentist names SELECT p.patient_id, full_name(d) AS dentist_name FROM patient p LEFT JOIN dentist d ON (p.dentist_id = d.dentist_id); If you know how this problem might be fixed, list the solution below: - Change the assertion protecting against this case in src/pl/plpgsql/src/pl_exec.c to an if statement, so that the row argument is only copied into the function's arguments if the row actually exists. Otherwise, a row with no columns is passed in to the function, which gets NULLs when it tries to access any of the row's columns. I think this is correct behavior -- if there was no row, then there should be no values passed into the function. See the attached file pl_exec.c.patch (diffed against postgresql 7.4.1). pl_exec.c.patch Description: Binary data Thanks! - 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: [PATCHES] Doing psql's lexing with flex
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Am I missing something, or is dollar quoting not in this patch? It is not. If we go this way, then we'd add essentially identical flex patches to backend and psql to implement dollar quoting (plus perhaps a few more lines in psql to support signaling dollar quoting in the prompt, but that's pretty trivial). My intent with the given patch was just to replicate existing functionality with flex. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Doing psql's lexing with flex
Tom Lane wrote: > I got interested enough in the psql-with-flex problem to go off and > solve it. Attached is a working patch, which I'm now debating > whether to apply. Comments solicited... That should teach me a lesson not to leave random comments lying around in the source code. Years later someone might take them seriously. :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
