Re: [PATCHES] clock_timestamp() and transaction_timestamp() function
Bruce Momjian writes: The goal was to give a unified API to the various time measurements: [clock|statement|transaction]_timestamp It would be very useful if we had a parameter that controlled whether current_timestamp maps to statement_timestamp or to transaction_timestamp. There seems to be quite some disagreement over this issue, and this would help resolve it and also prevent users from unnecessarily using nonstandard functions in their application. The name clock_timestamp seems kind of unfortunate. Where else would a time stamp come from if not from the clock? Why is this functionality needed anyway? It seems that it could only serve to produce nondeterministic, unreproduceable results. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Make pg_dump dump conversions
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I will try to apply it within the next 48 hours. This one's applied already, no? Yes, sorry. Removed. -- 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/docs/faqs/FAQ.html
Re: [PATCHES] Make pg_dump dump conversions
Patch already applied. --- Christopher Kings-Lynne wrote: Just noticed a bug in the previous version of the patch. Would fail against pre-7.3 postgres. Fixed in this new version. Just discard the old. Chris Christopher Kings-Lynne wrote: Save this for 7.5. Nails a TODO item. Chris ? GNUmakefile ? config.log ? config.status ? src/Makefile.global ? src/backend/postgres ? src/backend/access/common/.deps ? src/backend/access/gist/.deps ? src/backend/access/hash/.deps ? src/backend/access/heap/.deps ? src/backend/access/index/.deps ? src/backend/access/nbtree/.deps ? src/backend/access/rtree/.deps ? src/backend/access/transam/.deps ? src/backend/bootstrap/.deps ? src/backend/catalog/.deps ? src/backend/catalog/postgres.bki ? src/backend/catalog/postgres.description ? src/backend/commands/.deps ? src/backend/executor/.deps ? src/backend/lib/.deps ? src/backend/libpq/.deps ? src/backend/main/.deps ? src/backend/nodes/.deps ? src/backend/optimizer/geqo/.deps ? src/backend/optimizer/path/.deps ? src/backend/optimizer/plan/.deps ? src/backend/optimizer/prep/.deps ? src/backend/optimizer/util/.deps ? src/backend/parser/.deps ? src/backend/port/.deps ? src/backend/postmaster/.deps ? src/backend/regex/.deps ? src/backend/rewrite/.deps ? src/backend/storage/buffer/.deps ? src/backend/storage/file/.deps ? src/backend/storage/freespace/.deps ? src/backend/storage/ipc/.deps ? src/backend/storage/large_object/.deps ? src/backend/storage/lmgr/.deps ? src/backend/storage/page/.deps ? src/backend/storage/smgr/.deps ? src/backend/tcop/.deps ? src/backend/utils/.deps ? src/backend/utils/adt/.deps ? src/backend/utils/cache/.deps ? src/backend/utils/error/.deps ? src/backend/utils/fmgr/.deps ? src/backend/utils/hash/.deps ? src/backend/utils/init/.deps ? src/backend/utils/mb/.deps ? src/backend/utils/mb/conversion_procs/conversion_create.sql ? src/backend/utils/mb/conversion_procs/ascii_and_mic/.deps ? src/backend/utils/mb/conversion_procs/ascii_and_mic/libascii_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/.deps ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/libcyrillic_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/.deps ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/libeuc_cn_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/.deps ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0 ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/.deps ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/.deps ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0 ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/.deps ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/liblatin2_and_win1250.so.0 ? src/backend/utils/mb/conversion_procs/latin_and_mic/.deps ? src/backend/utils/mb/conversion_procs/latin_and_mic/liblatin_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/libutf8_and_ascii.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_big5/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_big5/libutf8_and_big5.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/libutf8_and_cyrillic.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/libutf8_and_euc_cn.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/libutf8_and_euc_jp.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/libutf8_and_euc_kr.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/libutf8_and_euc_tw.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/libutf8_and_gb18030.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/libutf8_and_gbk.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/libutf8_and_iso8859.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/libutf8_and_iso8859_1.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_johab/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_johab/libutf8_and_johab.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_sjis/.deps ?
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway wrote: Tom Lane wrote: One could make a good case that INDEX_MAX_KEYS should be exported along with FUNC_MAX_ARGS, rather than letting people write client code that assumes they are the same. I was intending to propose that we also export the following as read-only variables: * NAMEDATALEN * BLCKSZ * integer-vs-float datetime flag OK, the attached includes the above -- result looks like: regression=# select * from pg_settings where category like 'Compile%'; -[ RECORD 1 ]-- name | block_size OK. Should that be page_size? Not sure but block size sounds more like a hardware setting. I know we call it BLCKSZ in our code but page size seems more appropriate. Not sure. name | func_max_args name | index_max_keys Should that be max_func_args and max_index_args? Seems more natural. Should we spell out function? Probably. We already have check_*function*_bodies. name | integer_datetimes short_desc | Datetimes are integer based This one has me confused. Datetimes are integer based is a statement, as is the variable name. Should it be integer_datetime_storage or something else? name | name_data_len Is name a good description, or is identifier better, identifier_length? -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] introduce default_use_oids
Agreed. --- Peter Eisentraut wrote: Bruce Momjian writes: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. This parameter ought to be called default_with_oids, to reflect the actual effect. --- Neil Conway wrote: On Fri, 2003-10-10 at 05:56, Manfred Koizar wrote: On Tue, 30 Sep 2003 20:00:22 -0400, Neil Conway [EMAIL PROTECTED] wrote: This patch adds a new GUC var, default_use_oids Shouldn't it be honoured by CREATE TABLE AS SELECT ... ? Good catch. I've attached an updated patch. I also included a few improvements to the docs. I think it would be a good idea to extend CREATE TABLE AS to allow WITH OIDS and WITHOUT OIDS to be specified, so that it provides a better option for people who need OIDs in their CREATE TABLE AS-generated tables than manually setting the default_use_oids GUC var (CREATE TABLE AS should also accept ON COMMIT ..., for that matter). But implementing this will require changing the internal representation of CREATE TABLE AS to be something more than just a wrapper over SelectStmt, I believe. I haven't made this change in the attached patch, but I'll probably do it before 7.5 is released. Any comments? -Neil [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] ISO 8601 Time Intervals of the format with time-unit
Peter Eisentraut wrote: Bruce Momjian writes: Is this ready for application? It looks good to me. However, there is an Open issues section. It would be more useful to implement the SQL standard for intervals first instead of inventing more nonstandard formats for it. OK, patch removed from queue. -- 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: [PATCHES] clock_timestamp() and transaction_timestamp() function
Peter Eisentraut wrote: Bruce Momjian writes: The goal was to give a unified API to the various time measurements: [clock|statement|transaction]_timestamp It would be very useful if we had a parameter that controlled whether current_timestamp maps to statement_timestamp or to transaction_timestamp. There seems to be quite some disagreement over this issue, and this would help resolve it and also prevent users from unnecessarily using nonstandard functions in their application. The name clock_timestamp seems kind of unfortunate. Where else would a time stamp come from if not from the clock? Why is this functionality needed anyway? It seems that it could only serve to produce nondeterministic, unreproduceable results. Agreed. You are thinking a GUC like statement_current_timestamp which defaults to false? -- 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 8: explain analyze is your friend
Re: [PATCHES] clock_timestamp() and transaction_timestamp() function
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: It would be very useful if we had a parameter that controlled whether current_timestamp maps to statement_timestamp or to transaction_timestamp. This is a nonstarter, as is the previous proposal to have a single function with an explicit parameter that selects the behavior. The reason is that any such function would have to be treated as completely non-optimizable. It's really important that current_timestamp be STABLE so that queries like where entrytimestamp = current_timestamp - '10 minutes' can use an index. This means you can't have options that make it not be STABLE. Oh, I forgot about that. Peter seems only to want statement_timestamp and transaction_timestamp. Aren't those both stable if statement_timestamp is set from exec_simple_query? The name clock_timestamp seems kind of unfortunate. Agreed, it's not the best choice. Why is this functionality needed anyway? Performance measurements within plpgsql functions, for example. I am unconvinced that anyone has really proven the need for statement_timestamp, but a cleaner replacement for timeofday() would be nice to have. Yep, and if we say we need that then the GUC option doesn't work because the certainly will not be stable. -- 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: [PATCHES] clock_timestamp() and transaction_timestamp() function
Peter Eisentraut [EMAIL PROTECTED] writes: It would be very useful if we had a parameter that controlled whether current_timestamp maps to statement_timestamp or to transaction_timestamp. This is a nonstarter, as is the previous proposal to have a single function with an explicit parameter that selects the behavior. The reason is that any such function would have to be treated as completely non-optimizable. It's really important that current_timestamp be STABLE so that queries like where entrytimestamp = current_timestamp - '10 minutes' can use an index. This means you can't have options that make it not be STABLE. The name clock_timestamp seems kind of unfortunate. Agreed, it's not the best choice. Why is this functionality needed anyway? Performance measurements within plpgsql functions, for example. I am unconvinced that anyone has really proven the need for statement_timestamp, but a cleaner replacement for timeofday() would be nice to have. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] clock_timestamp() and transaction_timestamp() function
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: This is a nonstarter, Oh, I forgot about that. Peter seems only to want statement_timestamp and transaction_timestamp. Aren't those both stable if statement_timestamp is set from exec_simple_query? Hm. If you restricted the option to only those two values, it might be safe as far as the stability argument goes, but it would be the sort of thing where we'd have to be perpetually on our guard against someone making the obvious extension and thereby subtly breaking things. In general, I do not like options that subtly change the behavior of long-established functions, anyway. Seems like a great recipe for breaking people's applications. I'm okay with adding new functions as per the already-agreed-to set of names (though like Peter I wish we could think of something clearer than clock_timestamp()). Rejiggering the behavior of already-existing functions was not part of what had been agreed to. regards, tom lane ---(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] clock_timestamp() and transaction_timestamp() function
Tom Lane writes: This is a nonstarter, as is the previous proposal to have a single function with an explicit parameter that selects the behavior. The reason is that any such function would have to be treated as completely non-optimizable. Why? We would just need to ensure that the mode cannot be changed at critical times. I am unconvinced that anyone has really proven the need for statement_timestamp, Compatibility with other database systems might be one (if it is accessible through current_timestamp). -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] clock_timestamp() and transaction_timestamp() function
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: This is a nonstarter, as is the previous proposal to have a single function with an explicit parameter that selects the behavior. The reason is that any such function would have to be treated as completely non-optimizable. Why? We would just need to ensure that the mode cannot be changed at critical times. critical time being anywhere within a session, I guess? Either that or keep track of whether any cached plans depend on the stability assumption. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was:
Tom Lane writes: There was just a discussion a few days ago about the page size for large objects, for which the correct answer was BLCKSZ/4 IIRC. Whether people actually *should* care about the page size of large objects I dunno, but the fact is some of them *do* care. Maybe we should provide specific functions to access this information, so client applications don't have to hardcode these formulas. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: There was just a discussion a few days ago about the page size for large objects, for which the correct answer was BLCKSZ/4 IIRC. Whether people actually *should* care about the page size of large objects I dunno, but the fact is some of them *do* care. Maybe we should provide specific functions to access this information, so client applications don't have to hardcode these formulas. That's exactly what this thread is about: current_setting() is the proposed access function ... I'm not convinced that large object pagesize is interesting enough to deserve its own GUC variable, but if someone wanted to make that case I'm certainly open to listening. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Bruce, This seems like a valuable feature, as others have mentioned. However, should it also prevent changes to default_transaction_read_only? What is the use case for this functionality? I thought that this was rejected thouroughly by Tom some months ago. He argued pretty strongly that READ ONLY transactions were *not* a security feature and that trying to make them one would work very poorly. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway wrote: name | func_max_args name | index_max_keys Should that be max_func_args and max_index_args? Seems more natural. Should we spell out function? Probably. We already have check_*function*_bodies. Agreed. Now: name | max_function_args name | max_identifier_length name | max_index_keys Nice. name | integer_datetimes short_desc | Datetimes are integer based This one has me confused. Datetimes are integer based is a statement, as is the variable name. Should it be integer_datetime_storage or something else? Well the configure option is: --enable-integer-datetimes so integer_datetimes seemed natural to me. The description is a statement because the option is boolean, i.e. the statement Datetimes are integer based is either true or false (on or off, etc). How stongly do you feel about it? I don't think integer_datetime_storage is accurate in any case. Not strongly. Keep it unchanged. -- 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: [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Josh Berkus wrote: Bruce, This seems like a valuable feature, as others have mentioned. However, should it also prevent changes to default_transaction_read_only? What is the use case for this functionality? I thought that this was rejected thouroughly by Tom some months ago. He argued pretty strongly that READ ONLY transactions were *not* a security feature and that trying to make them one would work very poorly. I remember something like that, but I thought the patch was the result of that discussion. Tom? -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] clock_timestamp() and transaction_timestamp() function
Yes, user-visible. They give additional current timestamp information. transaction_timestamp() is the same as current_timestamp, clock_timestamp is the same as gettimeofday(), and statement_timestamp is a new one that shows statement start time. And what would be the point of that? Bean counters love this stuff, especially during audits. =D -- Randolf Richardson - [EMAIL PROTECTED] Vancouver, British Columbia, Canada Please do not eMail me directly when responding to my postings in the newsgroups. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Bruce Momjian wrote: Joe Conway wrote: The description is a statement because the option is boolean, i.e. the statement Datetimes are integer based is either true or false (on or off, etc). How stongly do you feel about it? I don't think integer_datetime_storage is accurate in any case. Not strongly. Keep it unchanged. Any more thoughts on block_size (or page_size)? Thanks, Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Minor lmgr code cleanup
Patch applied. Thanks. That lock manager code really needed the cleanup. --- Manfred Koizar wrote: On Mon, 8 Sep 2003 13:02:11 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: Manfred, can I get a description for this patch? Thanks. Try to reduce confusion about what is a lock method identifier, a lock method control structure, or a table of control structures. . Use type LOCKMASK where an int is not a counter. . Get rid of INVALID_TABLEID, use INVALID_LOCKMETHOD instead. . Use INVALID_LOCKMETHOD instead of (LOCKMETHOD) NULL, because LOCKMETHOD is not a pointer. . Define and use macro LockMethodIsValid. . Rename LOCKMETHOD to LOCKMETHODID. . Remove global variable LongTermTableId in lmgr.c, because it is never used. . Make LockTableId static in lmgr.c, because it is used nowhere else. Why not remove it and use DEFAULT_LOCKMETHOD? . Rename the lock method control structure from LOCKMETHODTABLE to LockMethodData. Introduce a pointer type named LockMethod. . Remove elog(FATAL) after InitLockTable() call in CreateSharedMemoryAndSemaphores(), because if something goes wrong, there is elog(FATAL) in LockMethodTableInit(), and if this doesn't help, an elog(ERROR) in InitLockTable() is promoted to FATAL. . Make InitLockTable() void, because its only caller does not use its return value any more. . Rename variables in lock.c to avoid statements like LockMethodTable[NumLockMethods] = lockMethodTable; lockMethodTable = LockMethodTable[lockmethod]; . Change LOCKMETHODID type to uint16 to fit into struct LOCKTAG. . Remove static variables BITS_OFF and BITS_ON from lock.c, because I agree to this doubt: * XXX is a fetch from a static array really faster than a shift? . Define and use macros LOCKBIT_ON/OFF. == All 93 tests passed. == Servus Manfred -- 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: [PATCHES] introduce default_use_oids
Updated patch applied. Thanks. --- Neil Conway wrote: This patch adds a new GUC var, default_use_oids, which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Comments are welcome. (This patch is for the 7.5 queue.) -Neil [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Joe Conway writes: Any more thoughts on block_size (or page_size)? It's always been some variant spelling of block size, and I see no reason to change the terminology. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [Fwd: [PATCHES] Make psql use all pretty print options]
Patch applied. Thanks.
The CHECK part of this patch was already applied to 7.4.
---
Christopher Kings-Lynne wrote:
Resubmission of patch (for 7.4).
I fixed the problems I was having what I chatted to you Bruce, I've
tested it well and it shouldn't be a problem to apply for 7.4. It looks
really nice with the pretty print stuff!
Chris
Original Message
Subject: [PATCHES] Make psql use all pretty print options
Date: Mon, 29 Sep 2003 12:31:18 +0800 (WST)
From: Christopher Kings-Lynne [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi,
This patch finishes off the work that I did with making view
definitions use pretty printing.
It does:
* Pretty check constraints
* Pretty index predicates
* Pretty rule definitions
* Uppercases PRIMARY KEY and UNIQUE to be consistent with CHECK and
FOREIGN KEY
* View rules are improved to match table rules:
View public.v
Column | Type | Modifiers
--+-+---
?column? | integer |
View definition:
SELECT 1;
Rules:
r1 AS
ON INSERT TO v DO INSTEAD NOTHING
r2 AS
ON INSERT TO v DO INSTEAD NOTHING
Chris
Index: describe.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/describe.c,v
retrieving revision 1.85
diff -c -r1.85 describe.c
*** describe.c7 Sep 2003 03:43:53 - 1.85
--- describe.c29 Sep 2003 04:24:56 -
***
*** 857,863
printfPQExpBuffer(buf,
SELECT i.indisunique, i.indisprimary, a.amname, c2.relname,\n
! pg_catalog.pg_get_expr(i.indpred,
i.indrelid)\n
FROM pg_catalog.pg_index i,
pg_catalog.pg_class c, pg_catalog.pg_class c2, pg_catalog.pg_am a\n
WHERE i.indexrelid = c.oid AND
c.oid = '%s' AND c.relam = a.oid\n
AND i.indrelid = c2.oid,
--- 857,863
printfPQExpBuffer(buf,
SELECT i.indisunique, i.indisprimary, a.amname, c2.relname,\n
! pg_catalog.pg_get_expr(i.indpred,
i.indrelid, true)\n
FROM pg_catalog.pg_index i,
pg_catalog.pg_class c, pg_catalog.pg_class c2, pg_catalog.pg_am a\n
WHERE i.indexrelid = c.oid AND
c.oid = '%s' AND c.relam = a.oid\n
AND i.indrelid = c2.oid,
***
*** 880,888
char *indpred = PQgetvalue(result, 0, 4);
if (strcmp(indisprimary, t) == 0)
! printfPQExpBuffer(tmpbuf, _(primary key, ));
else if (strcmp(indisunique, t) == 0)
! printfPQExpBuffer(tmpbuf, _(unique, ));
else
resetPQExpBuffer(tmpbuf);
appendPQExpBuffer(tmpbuf, %s, , indamname);
--- 880,888
char *indpred = PQgetvalue(result, 0, 4);
if (strcmp(indisprimary, t) == 0)
! printfPQExpBuffer(tmpbuf, _(PRIMARY KEY, ));
else if (strcmp(indisunique, t) == 0)
! printfPQExpBuffer(tmpbuf, _(UNIQUE, ));
else
resetPQExpBuffer(tmpbuf);
appendPQExpBuffer(tmpbuf, %s, , indamname);
***
*** 892,898
schemaname, indtable);
if (strlen(indpred))
! appendPQExpBuffer(tmpbuf, , predicate %s, indpred);
footers = xmalloczero(2 * sizeof(*footers));
footers[0] = xstrdup(tmpbuf.data);
--- 892,898
schemaname, indtable);
if (strlen(indpred))
! appendPQExpBuffer(tmpbuf, , predicate (%s),
indpred);
footers = xmalloczero(2 * sizeof(*footers));
footers[0] = xstrdup(tmpbuf.data);
***
*** 911,917
if (tableinfo.hasrules)
{
printfPQExpBuffer(buf,
! SELECT r.rulename\n
FROM pg_catalog.pg_rewrite
r\n
WHERE r.ev_class = '%s' AND r.rulename !=
'_RETURN',
oid);
--- 911,917
if
Re: [PATCHES] minor psql cleanup
Patch applied. Thanks. Someone had already removed the assert() from tab_complete.c, but not the #include assert.h. --- Neil Conway wrote: This patch reduces some unsightly #ifdefs, and fixes two typos in comments in the psql code. This doesn't make any functional change, so feel free to save it for 7.5 -Neil [ Attachment, skipping... ] ---(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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Make pg_dump dump conversions
Just to confirm --- this was applied to 7.4 already. --- Christopher Kings-Lynne wrote: Just noticed a bug in the previous version of the patch. Would fail against pre-7.3 postgres. Fixed in this new version. Just discard the old. Chris Christopher Kings-Lynne wrote: Save this for 7.5. Nails a TODO item. Chris ? GNUmakefile ? config.log ? config.status ? src/Makefile.global ? src/backend/postgres ? src/backend/access/common/.deps ? src/backend/access/gist/.deps ? src/backend/access/hash/.deps ? src/backend/access/heap/.deps ? src/backend/access/index/.deps ? src/backend/access/nbtree/.deps ? src/backend/access/rtree/.deps ? src/backend/access/transam/.deps ? src/backend/bootstrap/.deps ? src/backend/catalog/.deps ? src/backend/catalog/postgres.bki ? src/backend/catalog/postgres.description ? src/backend/commands/.deps ? src/backend/executor/.deps ? src/backend/lib/.deps ? src/backend/libpq/.deps ? src/backend/main/.deps ? src/backend/nodes/.deps ? src/backend/optimizer/geqo/.deps ? src/backend/optimizer/path/.deps ? src/backend/optimizer/plan/.deps ? src/backend/optimizer/prep/.deps ? src/backend/optimizer/util/.deps ? src/backend/parser/.deps ? src/backend/port/.deps ? src/backend/postmaster/.deps ? src/backend/regex/.deps ? src/backend/rewrite/.deps ? src/backend/storage/buffer/.deps ? src/backend/storage/file/.deps ? src/backend/storage/freespace/.deps ? src/backend/storage/ipc/.deps ? src/backend/storage/large_object/.deps ? src/backend/storage/lmgr/.deps ? src/backend/storage/page/.deps ? src/backend/storage/smgr/.deps ? src/backend/tcop/.deps ? src/backend/utils/.deps ? src/backend/utils/adt/.deps ? src/backend/utils/cache/.deps ? src/backend/utils/error/.deps ? src/backend/utils/fmgr/.deps ? src/backend/utils/hash/.deps ? src/backend/utils/init/.deps ? src/backend/utils/mb/.deps ? src/backend/utils/mb/conversion_procs/conversion_create.sql ? src/backend/utils/mb/conversion_procs/ascii_and_mic/.deps ? src/backend/utils/mb/conversion_procs/ascii_and_mic/libascii_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/.deps ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/libcyrillic_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/.deps ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/libeuc_cn_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/.deps ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0 ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/.deps ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/.deps ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0 ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/.deps ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/liblatin2_and_win1250.so.0 ? src/backend/utils/mb/conversion_procs/latin_and_mic/.deps ? src/backend/utils/mb/conversion_procs/latin_and_mic/liblatin_and_mic.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/libutf8_and_ascii.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_big5/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_big5/libutf8_and_big5.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/libutf8_and_cyrillic.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/libutf8_and_euc_cn.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/libutf8_and_euc_jp.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/libutf8_and_euc_kr.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/libutf8_and_euc_tw.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/libutf8_and_gb18030.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/libutf8_and_gbk.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/libutf8_and_iso8859.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/libutf8_and_iso8859_1.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_johab/.deps ? src/backend/utils/mb/conversion_procs/utf8_and_johab/libutf8_and_johab.so.0 ? src/backend/utils/mb/conversion_procs/utf8_and_sjis/.deps ?
Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable
Peter Eisentraut wrote: Joe Conway writes: Any more thoughts on block_size (or page_size)? It's always been some variant spelling of block size, and I see no reason to change the terminology. Yes, that is from a coder's perspective, but from the user/admin perspective, it seems more like page, and in fact we probably would call it page if we were starting from scratch. -- 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: [PATCHES] 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
Thomas Baden [EMAIL PROTECTED] writes: Hi there. My install was failing the regression tests due to a shared memory error. After reviewing the proposed patch, I find it hard to believe that the patch would have fixed any such problem --- even if key_t is 64 bits on your system, the code should still have worked, because we'd never have selected a key value wider than 32 bits anyway. What *exact* misbehavior were you seeing? regards, tom lane ---(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] psql: \dg and groups for \du
Nice:
test= create group test;
CREATE GROUP
test= \dg
List of database groups
Group name | Group ID
+--
test | 100
(1 row)
test= alter group test add user postgres;
ALTER GROUP
test= \du
List of database users
User name | User ID | Attributes | Groups
---+-++
postgres | 1 | superuser, create database | {test}
(1 row)
Patch applied, docs added, TODO updated. Thanks.
---
Markus Bertheau wrote:
Hi,
attached is a patch that adds display of the groups a user belongs to to
\du and a \dg command to psql. It's against 7.4beta5.
--
Markus Bertheau [EMAIL PROTECTED]
[ Attachment, skipping... ]
---(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
---(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] Win32 patch for Makefile.shlib
Patch applied. Thanks. --- Claudio Natoli wrote: If this is acceptable, I'll send a similar one for src/backend/Makefile Cheers, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 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 [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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 8: explain analyze is your friend
Re: [PATCHES] improve psql lo_* help
Patch applied. Thanks.
---
Christopher Kings-Lynne wrote:
This makes help like this:
\lo_export LOBOID FILE
\lo_import FILE [COMMENT]
\lo_list
\lo_unlink LOBOIDlarge object operations
Instead of not saying anything about what arguments are required.
Chris
Index: src/bin/psql/help.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/help.c,v
retrieving revision 1.81
diff -c -r1.81 help.c
*** src/bin/psql/help.c 2 Oct 2003 06:39:31 - 1.81
--- src/bin/psql/help.c 17 Nov 2003 09:02:23 -
***
*** 245,254
fprintf(output, _(Copy, Large Object\n));
fprintf(output, _( \\copy ... perform SQL COPY with data stream to the
client host\n));
! fprintf(output, _( \\lo_export\n
! \\lo_import\n
\\lo_list\n
! \\lo_unlink large object
operations\n));
if (output != stdout)
{
--- 245,254
fprintf(output, _(Copy, Large Object\n));
fprintf(output, _( \\copy ... perform SQL COPY with data stream to the
client host\n));
! fprintf(output, _( \\lo_export LOBOID FILE\n
! \\lo_import FILE [COMMENT] \n
\\lo_list\n
! \\lo_unlink LOBOIDlarge object
operations\n));
if (output != stdout)
{
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] introduce default_use_oids
On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote: Neil Conway wrote: This patch adds a new GUC var, default_use_oids, which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Comments are welcome. Hum, sorry to be late, but wasn't one of the supposed strenghts of pg_dump supposed to be that you could take a dump and load it on a different RDBMS? I haven't tried it so I don't know if it works, but this patch takes out the ability to do that -- no one else will accept WITH/WITHOUT OIDS, so the dump will have to be modified. Is a switch provided to stop the emission of those modifiers? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Escucha y olvidarás; ve y recordarás; haz y entenderás (Confucio) ---(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] 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
On Mon, Dec 01, 2003 at 05:19:17PM -0500, Tom Lane wrote: Thomas Baden [EMAIL PROTECTED] writes: Hi there. My install was failing the regression tests due to a shared memory error. After reviewing the proposed patch, I find it hard to believe that the patch would have fixed any such problem --- even if key_t is 64 bits on your system, the code should still have worked, because we'd never have selected a key value wider than 32 bits anyway. What *exact* misbehavior were you seeing? It's not the key (key_t) that is the problem, but the size, which used to be int but got replaced by a size_t. Kurt ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] psql: \dg and groups for \du
Note that it is planned to unify users and groups into a general role
entity, so this command is probably going to go away soon.
Bruce Momjian writes:
Nice:
test= create group test;
CREATE GROUP
test= \dg
List of database groups
Group name | Group ID
+--
test | 100
(1 row)
test= alter group test add user postgres;
ALTER GROUP
test= \du
List of database users
User name | User ID | Attributes | Groups
---+-++
postgres | 1 | superuser, create database | {test}
(1 row)
Patch applied, docs added, TODO updated. Thanks.
---
Markus Bertheau wrote:
Hi,
attached is a patch that adds display of the groups a user belongs to to
\du and a \dg command to psql. It's against 7.4beta5.
--
Markus Bertheau [EMAIL PROTECTED]
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] introduce default_use_oids
Alvaro Herrera writes: On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote: Neil Conway wrote: This patch adds a new GUC var, default_use_oids, which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Comments are welcome. Hum, sorry to be late, but wasn't one of the supposed strenghts of pg_dump supposed to be that you could take a dump and load it on a different RDBMS? I haven't tried it so I don't know if it works, but this patch takes out the ability to do that -- no one else will accept WITH/WITHOUT OIDS, so the dump will have to be modified. Is a switch provided to stop the emission of those modifiers? I agree with that. By default, WITH/WITHOUT OIDS should not be dumped. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] psql: \dg and groups for \du
Peter Eisentraut wrote: Note that it is planned to unify users and groups into a general role entity, so this command is probably going to go away soon. NP, at least the code is there for reuse. -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Josh Berkus wrote: I thought that this was rejected thouroughly by Tom some months ago. He argued pretty strongly that READ ONLY transactions were *not* a security feature and that trying to make them one would work very poorly. I remember something like that, but I thought the patch was the result of that discussion. Tom? Hm, I can't find anything in the archives in which I said that. I did argue that using GUC to control a security feature would be a mistake: http://archives.postgresql.org/pgsql-patches/2003-07/msg00198.php and after watching Bruce struggle with trying to make logging-related GUC settings secure, I think my point is pretty much proved ;-). I don't want to see more cruft like that added to the GUC logic. http://archives.postgresql.org/pgsql-patches/2003-07/msg00204.php Sure sounds like you said READ ONLY xacts can't be used for security. :) Another thing to think about is that the semantics of START TRANSACTION READ ONLY are constrained by the SQL standard, and they are not exactly read only in the traditional sense (eg, you can still create and use temp tables). If we go down this path, I would be unsurprised to run into a showstopper conflict between what's needed for reasonably secure behavior and what the spec dictates. It would be less risky to use some other approach, if we are really interested in creating read-only users. Hence the term, security policy. I want read only users/transactions, but I also need temp tables to work and for transactions to be committed out of temp tables into the real tables via a proc with elevated privs. Other people who don't want to have malicious read only users fill up the disk may want TEMP tables to be disabled. So I'm still of the opinion I gave in the above-mentioned thread, that I'd rather make read only user be a concept driven by a flag in the user's pg_shadow entry. I think a boolean read only user flag will fall well short of letting admins finely tune the database's behavior given the example above. I think using ALTER USER [username] SET is a much better mechanism for securing users than setting a boolean in pg_shadow. Taking the boolean in pg_shadow to its extreme, we'll either get to the point where we've got a gazillion different columns (think of how nasty MySQL's mysql database and it's host/user/table/db is) that are unneeded 99% of the time. sarcasmTo avoid that, we could get smart and replace the single boolean value with an int4 options field where we could toggle various bits to mean different things. Bit 1 would be read only. Bit 2 would be allow temp tables. Then we could teach admins to xor bits and negate bits and hope that no one makes a mistake, thus opening up their DB to abuse because the admin made a mistake because instead of bit 15, they flipped bit 14, nevermind that we'll have made the assumption that every DBA has a good working understanding of binary./sarcasm The patch doesn't prevent write(2), but this tunable isn't used to prevent writing to disk, it's meant to prevent changes to the database by a given user. If you want a truly read-only database (in the case of NFS), mount the filesystem as readonly (not sure if that works, but it'd be a useful exercise). One step better, centralize the postmaster's write() calls and add a level of indirection with a few function pointers. If the backend is in read-only mode, use a different func that aborts the transaction. I think Tom's big objection is the abuse of the GUC system for maintaining this information. Having thought about this some, I think the GUC system is pretty well suited for this and that Tom's objection (correct me if I'm wrong here) is that GUC has a non-hierarchical naming structure/convention. With a hierarchical structure, lumping of GUC variables becomes more reasonable and the naming is more systematic. Instead of, jail_read_only_transaction=true it'd be security.force_readonly=true or transaction.readonly_always=true. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] cleanup execTuples.c
Patch applied. Thanks. --- Neil Conway wrote: Tom Lane [EMAIL PROTECTED] writes: Please use names for the replacement routines that are more clear than fooInternal. You can get away with that kind of name for a static function, but I think globally visible ones should have more meaningful names. The only function I named fooInternal was ExecTypeFromTLInternal, which is static. For ExecTypeFromTLInternal, maybe use ExecTupDescFromTL, which is a more accurate name in the first place What's the logic in having ExecTypeFromTL() and ExecCleanTypeFromTL() implemented in terms of a function called ExecTupDescFromTL()? i.e. if we're going to be renaming functions, wouldn't it make sense to rename the public API functions, not the internal static functions? As for the Slot functions, I agree with getting rid of the macros, which seem to add little except obfuscation. But I see no need to introduce an extra layer of calls. Why not make them all go directly to ExecAllocTableSlot(estate-es_tupleTable)? Yeah, I was considering that, both ways seemed about equal to me. Attached is a revised version of the patch. I've adopted Tom's suggestion for the slot functions. For renaming ExecTypeFromTLInternal(), I haven't changed the name of the function (see my comments above), but if you clarify what you're suggesting, I can submit another version of the patch. BTW, this code includes the comment: *Currently there are about 4 different places where we create *TupleDescriptors. They should all be merged, or perhaps be *rewritten to call BuildDesc(). Aside from the fact that BuildDesc() doesn't exist anymore AFAICS, would this still be a reasonable reorganization to make? -Neil [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
Kurt Roeckx [EMAIL PROTECTED] writes: On Mon, Dec 01, 2003 at 05:19:17PM -0500, Tom Lane wrote: After reviewing the proposed patch, I find it hard to believe that the patch would have fixed any such problem --- It's not the key (key_t) that is the problem, but the size, which used to be int but got replaced by a size_t. I don't see a problem there either. We don't create shmem segments larger than 2Gb (and if we wanted to do so, this patch certainly isn't enough to get it done --- all the arithmetic for shmem sizing is int). regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Sean Chittenden wrote: I think Tom's big objection is the abuse of the GUC system for maintaining this information. Having thought about this some, I think the GUC system is pretty well suited for this and that Tom's objection (correct me if I'm wrong here) is that GUC has a non-hierarchical naming structure/convention. With a hierarchical structure, lumping of GUC variables becomes more reasonable and the naming is more systematic. Instead of, jail_read_only_transaction=true it'd be security.force_readonly=true or transaction.readonly_always=true. Agreed on the usefulness of GUC. I had trouble adding security for logging settings not because GUC wouldn't work but because the logging control had to hit several different variables that all had different API's. It had to allow _increase_ for some variables and not others. -- 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 8: explain analyze is your friend
Re: [PATCHES] YA Cygwin DLLIMPORT patch
Patch applied. Thanks. --- Jason Tishler wrote: The attached patch enables contrib/cube to build cleanly under Cygwin (again). Please consider this patch for the 7.4.1 branch (if there will be one) too. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] introduce default_use_oids
Peter Eisentraut wrote: Alvaro Herrera writes: On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote: Neil Conway wrote: This patch adds a new GUC var, default_use_oids, which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Comments are welcome. Hum, sorry to be late, but wasn't one of the supposed strenghts of pg_dump supposed to be that you could take a dump and load it on a different RDBMS? I haven't tried it so I don't know if it works, but this patch takes out the ability to do that -- no one else will accept WITH/WITHOUT OIDS, so the dump will have to be modified. Is a switch provided to stop the emission of those modifiers? I agree with that. By default, WITH/WITHOUT OIDS should not be dumped. Yes, I see that now: CREATE TABLE x ( y integer ) WITH OIDS; We need a solution to this. One idea is to use SET to change the default_with_oids setting when a table changes characteristics. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] introduce default_use_oids
Bruce Momjian [EMAIL PROTECTED] writes: We need a solution to this. I'm really not sure we do: the SQL produced by pg_dump was totally non-portable before, and it is slightly less portable now. ISTM that you will almost always need to do some post-processing of pg_dump's output to have any hope of loading it into another RDBMS in any case. A flag for pg_dump that told it to produce standards-compliant SQL would be a cool thing to have, but that would provide a solution to a problem that has always existed, not one that is introduced by this patch. One idea is to use SET to change the default_with_oids setting when a table changes characteristics. It is easy to do this if people think it would improve things. I didn't do it myself because I didn't see how it helped: SET is not in the standard either. It is just as trivial to use sed/perl/etc. to remove SET default_with_oids ... as it is to remove WITH/WITHOUT OIDS. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
http://archives.postgresql.org/pgsql-patches/2003-07/msg00204.php Sure sounds like you said READ ONLY xacts can't be used for security. :) Better read it again then. Okay: It's not intended to be a security measure, and I would strongly resist any attempt to make it so along the lines you propose. And strong resist in tgl-speak means, over my dead body, it ain't gunna happen. :) I think Tom's big objection is the abuse of the GUC system for maintaining this information. Check. Having thought about this some, I think the GUC system is pretty well suited for this and that Tom's objection (correct me if I'm wrong here) is that GUC has a non-hierarchical naming structure/convention. Not in the least. My objection to using GUC for this is that it's not designed to be non-subvertible; rather it's designed to allow settings to come from nearly anywhere. To get around that, you have to kluge it horribly. Poster child, once again, the cruft Bruce put into the logging settings --- not only is that ugly, but I have very little confidence that it doesn't still have holes. Complexity is not a virtue in security-related code; and any security expert will tell you that having the same code serving both security- and non-security-related goals is a recipe for disaster. It's too easy to break security while you are fooling with something you think is unrelated. Far be it for me to disagree with your points. Can I clarify what you're saying then with the following statement: A GUC-like system that is specific for containing security related settings would be okay, but GUC as it stands in its current incarnation, should not (at least with any illusion of providing security) be used for anything that is security related. And if I'm wrong in those assertions, can you comment on how you would do this with a tunable definition of read only? And if you agree with the above statement, do you have any thoughts on improving GUC so that it could potentially be more secure or secure enough? Anything that is written in C clobbers any attempt at being secure. What in side of the backend do you trust? -sc -- Sean Chittenden ---(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] export FUNC_MAX_ARGS as a read-only GUC variable
Bruce Momjian wrote: Peter Eisentraut wrote: Joe Conway writes: Any more thoughts on block_size (or page_size)? It's always been some variant spelling of block size, and I see no reason to change the terminology. Yes, that is from a coder's perspective, but from the user/admin perspective, it seems more like page, and in fact we probably would call it page if we were starting from scratch. Hmm, I don't feel strongly either way on this, but I guess I lean toward block_size myself. Any other opinions out there? block_size or page_size or something else? Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Index creation takes for ever
Manfred Koizar [EMAIL PROTECTED] writes: comparetup_index() compares two IndexTuples. The structure IndexTupleData consists basically of not much more than an ItemPointer, and the patch is not much more than adding a comparison of two ItemPointers. So how does the patch introduce a new low level implementation dependency? Because it sorts on tuple position, which is certainly about as low level as you can get. More to the point, though, no evidence has been provided that this is a good idea. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [BUGS] PATCH: Uninitialized variable usage in contrib/pg_autovacuum
Patch applied. Thanks. --- Craig Boston wrote: Sorry about the cross-post -- I'm not 100% sure which list this should be sent to. I noticed in the 7.4 release that in contrib/pg_autovacuum, args-logfile is not initialized if a log file is not specified on the command line. This causes an immediate segfault on systems that fill allocated memory with some value other than zero (my FreeBSD machine uses 0xD0). Several crashes later I discovered that args-user, password, host, and port are also used without being initialized. This doesn't appear to be fixed in CVS and I came up empty on a mailing list search -- hope it hasn't been reported already. Attached is a quick patch that fixes the problem. -- Craig [ Attachment, skipping... ] ---(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) 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] [BUGS] PATCH: Uninitialized variable usage in contrib/pg_autovacuum
Patch applied to 7.4.X too. --- Craig Boston wrote: Sorry about the cross-post -- I'm not 100% sure which list this should be sent to. I noticed in the 7.4 release that in contrib/pg_autovacuum, args-logfile is not initialized if a log file is not specified on the command line. This causes an immediate segfault on systems that fill allocated memory with some value other than zero (my FreeBSD machine uses 0xD0). Several crashes later I discovered that args-user, password, host, and port are also used without being initialized. This doesn't appear to be fixed in CVS and I came up empty on a mailing list search -- hope it hasn't been reported already. Attached is a quick patch that fixes the problem. -- Craig [ Attachment, skipping... ] ---(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) 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] [PATCH] Re: [pgsql-advocacy] Why READ ONLY
Bruce Momjian [EMAIL PROTECTED] writes: I assume this patch is to control this way of breaking out of a read-only transaction: [...] This seems like a valuable feature, as others have mentioned. Why is this feature valuable? A read only user is still able to easily DOS the server, consume arbitrary disk space[1], and prevent other users from accessing data (using LOCK, for example). It has been a long-standing fact that giving a user the ability to execute arbitrary SQL is a security hole; if you plan to change that, ISTM that a lot more work is necessary. -Neil [1] Whether they are allowed to create temp tables or not: plenty of other parts of the executor use temporary storage. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] introduce default_use_oids
Neil Conway writes: I'm really not sure we do: the SQL produced by pg_dump was totally non-portable before, Significant effort has been invested to make pg_dump output portable, and I've not had any problems with it last time I tried it. Please explain why you think it's totally non-portable. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] introduce default_use_oids
Hum, sorry to be late, but wasn't one of the supposed strenghts of pg_dump supposed to be that you could take a dump and load it on a different RDBMS? I haven't tried it so I don't know if it works, but this patch takes out the ability to do that -- no one else will accept WITH/WITHOUT OIDS, so the dump will have to be modified. Is a switch provided to stop the emission of those modifiers? There are so many other incompatibilities in our dumps anyway! Anyway, our first loyalty is to PostgreSQL... If someone can't run a sed script to 's/WITH OIDS//g', then they're going to have a LOT of problems... Chris ---(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] YA Cygwin DLLIMPORT patch
Did you commit to 7.4.1 too Bruce? Chris Bruce Momjian wrote: Patch applied. Thanks. --- Jason Tishler wrote: The attached patch enables contrib/cube to build cleanly under Cygwin (again). Please consider this patch for the 7.4.1 branch (if there will be one) too. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 [ Attachment, skipping... ] ---(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
Re: [PATCHES] introduce default_use_oids
Significant effort has been invested to make pg_dump output portable, and I've not had any problems with it last time I tried it. Please explain why you think it's totally non-portable. Functions, indexes, operators, types, aggregates, users, groups, databases, inheritance, clustering, col stats, col storage, ... What IS compatible? Very basic table definitions? Chris ---(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
