Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
David Fetter wrote: > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > > Here is the patches he made against CVS HEAD (as of today). > > The git repository should now match this :) > > http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary > > Apparently, it's easiest to clone via the following URL: > > http://git.postgresql.org/git/~davidfetter/postgresql/.git > > Is there some git repository I can pull from to make this a little > less manual? In fact, I fail to see the point of you providing the repo if the upstream guys are apparently not using it ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > Here is the patches he made against CVS HEAD (as of today). The git repository should now match this :) http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary Apparently, it's easiest to clone via the following URL: http://git.postgresql.org/git/~davidfetter/postgresql/.git Is there some git repository I can pull from to make this a little less manual? Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] page macros cleanup (ver 04)
Pavan, Heikki, Is it OK now or do you have any comments? Thanks Zdenek Zdenek Kotala napsal(a): Pavan Deolasee napsal(a): On Fri, Jul 4, 2008 at 4:25 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: No, there's a itemsz = MAXALIGN(itemsz) call before the check against HashMaxItemSize. Ah, right. Still should we just not MAXALIGN_DOWN the Max size to reflect the practical limit on the itemsz ? It's more academical though, so not a big deal. Finally I use following formula: #define HashMaxItemSize(page) \ MAXALIGN_DOWN(PageGetPageSize(page) - \ ( SizeOfPageHeaderData + sizeof(ItemIdData) ) - \ MAXALIGN(sizeof(HashPageOpaqueData)) ) I did not replace PageGetPageSize(page), because other *MaxItemSize has same interface. Revised patch is attached. Zdenek -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets
Josh Berkus wrote: Tom, Indeed. If the Solaris folk feel that getupeercred() is insecure, they had better explain why their kernel is that broken. This is entirely unrelated to the known shortcomings of the "ident" IP protocol. The Solaris security & kernel folks do, actually. However, there's no question that TRUST is inherently insecure, and that's what people are going to use if they can't get IDENT to work. I'd be *very* interested in how they come to that assessment. I'd have thought that the only alternative to getpeereid/getupeercred is password-based or certificate-based authenticated - which seem *less* secure because a) they also rely on the client having the correct uid or gid (to read the password/private key), plus b) the risk of the password/private key getting into the wrong hands. How is that sort of authenticated handled by services shipping with solaris? regards, Florian Pflug, hoping to be enlightened beyond his limited posix-ish view of the world... -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] GIN improvements
Teodor Sigaev <[EMAIL PROTECTED]> writes: >> I looked this over and it looks good in general. > May I think that patch passed review and commit it? I'd still like to take a look. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] GIN improvements
I looked this over and it looks good in general. May I think that patch passed review and commit it? -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets
Josh Berkus wrote: Tom, Indeed. If the Solaris folk feel that getupeercred() is insecure, they had better explain why their kernel is that broken. This is entirely unrelated to the known shortcomings of the "ident" IP protocol. The Solaris security & kernel folks do, actually. However, there's no question that TRUST is inherently insecure, and that's what people are going to use if they can't get IDENT to work. I think I'd pose a slightly different question from Tom. Do the Solaris devs think that their getupeercred() is more insecure than the more or less equivalent calls that we are doing on Linux and *BSD for example? I suspect they probably don't ;-) cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Solaris ident authentication using unix domain sockets
Tom, > Indeed. If the Solaris folk feel that getupeercred() is insecure, > they had better explain why their kernel is that broken. This is > entirely unrelated to the known shortcomings of the "ident" IP > protocol. The Solaris security & kernel folks do, actually. However, there's no question that TRUST is inherently insecure, and that's what people are going to use if they can't get IDENT to work. -- Josh Berkus PostgreSQL @ Sun San Francisco -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Extending grant insert on tables to sequences
On 7/8/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Jaime Casanova escribió: > > On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > The idea of this patch is to avoid the need to make explicit grants on > > > sequences owned by tables. > > > > I've noted that the patch i attached is an older version that doesn't > > compile because of a typo... > > Re-attaching right patch and fix documentation to indicate the new > > behaviour... > > I had a look at this patch and it looks good. The only thing that's not > clear to me is whether we have agreed we want this to be the default > behavior? > mmm... i don't remember from where i took the equivalences... i will review if there is any concensus in that... anyway now i when people should speak about it... > > Wouldn't it be clearer to build a list with all the sequences owned by > the tables in istmt.objects, and then call ExecGrantStmt_oids() a single > time with the big list? > at night i will see the code for this... -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Guayaquil - Ecuador Cel. (593) 87171157 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Add missing descriptions for aggregates, functions and conversions
Please find attached a patch that adds some missing descriptions for
aggregates, functions and conversions. This will add COMMENTs to the
conversion sql script as well. Most of the descriptions are taken from the
documentation (especially for the statistic functions). I didn't bother
with some internal functions like text_pattern_lt, if we agree they should
be described as well i can add them, too.
--
Thanks
Bernd? function_descr.patch
Index: src/backend/utils/mb/conversion_procs/Makefile
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/mb/conversion_procs/Makefile,v
retrieving revision 1.19
diff -c -b -r1.19 Makefile
*** src/backend/utils/mb/conversion_procs/Makefile 18 Mar 2008 16:24:50 - 1.19
--- src/backend/utils/mb/conversion_procs/Makefile 8 Jul 2008 15:06:47 -
***
*** 175,182
--- 175,184
obj=$$1; shift; \
echo "-- $$se --> $$de"; \
echo "CREATE OR REPLACE FUNCTION $$func (INTEGER, INTEGER, CSTRING, INTERNAL, INTEGER) RETURNS VOID AS '$$"libdir"/$$obj', '$$func' LANGUAGE C STRICT;"; \
+ echo "COMMENT ON FUNCTION $$func(INTEGER, INTEGER, CSTRING, INTERNAL, INTEGER) IS 'internal conversion function for $$se to $$de';"; \
echo "DROP CONVERSION pg_catalog.$$name;"; \
echo "CREATE DEFAULT CONVERSION pg_catalog.$$name FOR '$$se' TO '$$de' FROM $$func;"; \
+ echo "COMMENT ON CONVERSION pg_catalog.$$name IS 'conversion for $$se to $$de';"; \
done > $@
else
echo "-- No conversion support, for lack of shared library support" > $@
Index: src/include/catalog/pg_proc.h
===
RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.504
diff -c -b -r1.504 pg_proc.h
*** src/include/catalog/pg_proc.h 3 Jul 2008 20:58:46 - 1.504
--- src/include/catalog/pg_proc.h 8 Jul 2008 15:06:47 -
***
*** 235,241
DATA(insert OID = 110 ( unknownout PGNSP PGUID 12 1 0 f f t f i 1 2275 "705" _null_ _null_ _null_ unknownout - _null_ _null_ ));
DESCR("I/O");
DATA(insert OID = 111 ( numeric_fac PGNSP PGUID 12 1 0 f f t f i 1 1700 "20" _null_ _null_ _null_ numeric_fac - _null_ _null_ ));
!
DATA(insert OID = 115 ( box_above_eq PGNSP PGUID 12 1 0 f f t f i 2 16 "603 603" _null_ _null_ _null_ box_above_eq - _null_ _null_ ));
DESCR("is above (allows touching)");
DATA(insert OID = 116 ( box_below_eq PGNSP PGUID 12 1 0 f f t f i 2 16 "603 603" _null_ _null_ _null_ box_below_eq - _null_ _null_ ));
--- 235,241
DATA(insert OID = 110 ( unknownout PGNSP PGUID 12 1 0 f f t f i 1 2275 "705" _null_ _null_ _null_ unknownout - _null_ _null_ ));
DESCR("I/O");
DATA(insert OID = 111 ( numeric_fac PGNSP PGUID 12 1 0 f f t f i 1 1700 "20" _null_ _null_ _null_ numeric_fac - _null_ _null_ ));
! DESCR("equivalent to factorial");
DATA(insert OID = 115 ( box_above_eq PGNSP PGUID 12 1 0 f f t f i 2 16 "603 603" _null_ _null_ _null_ box_above_eq - _null_ _null_ ));
DESCR("is above (allows touching)");
DATA(insert OID = 116 ( box_below_eq PGNSP PGUID 12 1 0 f f t f i 2 16 "603 603" _null_ _null_ _null_ box_below_eq - _null_ _null_ ));
***
*** 3220,3340
--- 3220,3444
/* Aggregates (moved here from pg_aggregate for 7.3) */
DATA(insert OID = 2100 ( avgPGNSP PGUID 12 1 0 t f f f i 1 1700 "20" _null_ _null_ _null_ aggregate_dummy - _null_ _null_ ));
+ DESCR("the average (arithmetic mean) as numeric of all bigint values");
DATA(insert OID = 2101 ( avgPGNSP PGUID 12 1 0 t f f f i 1 1700 "23" _null_ _null_ _null_ aggregate_dummy - _null_ _null_ ));
+ DESCR("the average (arithmetic mean) as numeric of all integer values");
DATA(insert OID = 2102 ( avgPGNSP PGUID 12 1 0 t f f f i 1 1700 "21" _null_ _null_ _null_ aggregate_dummy - _null_ _null_ ));
+ DESCR("the average (arithmetic mean) as numeric of all smallint values");
DATA(insert OID = 2103 ( avgPGNSP PGUID 12 1 0 t f f f i 1 1700 "1700" _null_ _null_ _null_ aggregate_dummy - _null_ _null_ ));
+ DESCR("the average (arithmetic mean) as numeric of all numeric values");
DATA(insert OID = 2104 ( avgPGNSP PGUID 12 1 0 t f f f i 1 701 "700" _null_ _null_ _null_ aggregate_dummy - _null_ _null_ ));
+ DESCR("the average (arithmetic mean) as float8 of all float4 values");
DATA(insert OID = 2105 ( avgPGNSP PGUID 12 1 0 t f f f i 1 701 "701" _null_ _null_ _null_ aggregate_dummy - _null_ _null_ ));
+ DESCR("the average (arithmetic mean) as float8 of all float8 values");
DATA(insert OID = 2106 ( avgPGNSP PGUID 12 1 0 t f f f i 1 1186 "1186" _null_ _null_ _null_ aggregate_dummy - _null_ _null_ ));
+ DESCR("the average (arithmetic mean) as interval of all interval values");
DATA(insert OID = 2107 ( sumPGNSP PGUID 12 1 0 t f f f i 1 1700 "20" _null_ _null_ _null_ aggregate_dummy - _null_ _null
Re: [PATCHES] Bug fix for pg_standby keepfiles calculation
Simon Riggs wrote: Fix minor bug in pg_standby, noted by Ferenc Felhoffer Applied, thanks. I couldn't find a bug report from Ferenc in the archives. Did he contact you personally? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Extending grant insert on tables to sequences
Jaime Casanova escribió:
> On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > The idea of this patch is to avoid the need to make explicit grants on
> > sequences owned by tables.
>
> I've noted that the patch i attached is an older version that doesn't
> compile because of a typo...
> Re-attaching right patch and fix documentation to indicate the new
> behaviour...
I had a look at this patch and it looks good. The only thing that's not
clear to me is whether we have agreed we want this to be the default
behavior?
A quibble:
> + foreach(cell, istmt.objects)
> + {
> + [...]
> +
> + istmt_seq.objects = getOwnedSequences(lfirst_oid(cell));
> + if (istmt_seq.objects != NIL)
> + {
> + if (istmt.privileges & (ACL_INSERT))
> + istmt_seq.privileges |= ACL_USAGE;
> + else if (istmt.privileges & (ACL_UPDATE))
> + istmt_seq.privileges |= ACL_UPDATE;
> + else if (istmt.privileges & (ACL_SELECT))
> + istmt_seq.privileges |= ACL_SELECT;
> +
> + ExecGrantStmt_oids(&istmt_seq);
> + }
Wouldn't it be clearer to build a list with all the sequences owned by
the tables in istmt.objects, and then call ExecGrantStmt_oids() a single
time with the big list?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
Here is the patches he made against CVS HEAD (as of today). According to him followings are fixed with the patches: - fix crush with DISTINCT - fix creating VIEW - fix the case when recursion plan has another recursion plan under it - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result - fix inifinit recursion with OUTER JOIN Not yet fixed: - detect certain queries those are not valid acroding to the standard - sort query names acording to the dependency - planner always estimate 0 cost for recursion plans -- Tatsuo Ishii SRA OSS, Inc. Japan > > - SQL:2008 に規定されているクエリ以外をエラーにする処理 > > - 依存関係の順番で評価するようにする仕組み > > - プランナが常にコスト 0 で見積る > > > On Mon, Jul 07, 2008 at 04:22:21PM +0900, Yoshiyuki Asaba wrote: > > Hi, > > > > > test=# explain select count(*) > > > test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL > > > SELECT DISTINCT n+1 FROM t ) > > > test(# SELECT * FROM t WHERE n < 50) as t > > > test-# WHERE n < 100; > > > server closed the connection unexpectedly > > > This probably means the server terminated abnormally > > > before or while processing the request. > > > The connection to the server was lost. Attempting reset: Failed. > > > !> \q > > > > > > this one will kill the planner :( > > > removing the (totally stupid) distinct avoids the core dump. > > > > Thanks. I've fixed on local repository. > > Asaba-san, do you have a patch against CVS HEAD or against the > previous one? > > Cheers, > David. > -- > David Fetter <[EMAIL PROTECTED]> http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: [EMAIL PROTECTED] > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate recursive_query-8.patch.bz2 Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Userset logging
On Mon, 2008-07-07 at 16:13 +0100, Simon Riggs wrote:
> I notice log_temp_files is a PGC_USERSET parameter, which is out of step
> with our current thinking on who is allowed to initiate logging.
>
> Is there a rationale for this? Or should we set this to PGC_SUSET like
> all the other logging functions?
Patch enclosed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/utils/misc/guc.c
===
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.461
diff -c -r1.461 guc.c
*** src/backend/utils/misc/guc.c 1 Jul 2008 21:07:33 - 1.461
--- src/backend/utils/misc/guc.c 8 Jul 2008 06:03:18 -
***
*** 1861,1867
},
{
! {"log_temp_files", PGC_USERSET, LOGGING_WHAT,
gettext_noop("Log the use of temporary files larger than this number of kilobytes."),
gettext_noop("Zero logs all files. The default is -1 (turning this feature off)."),
GUC_UNIT_KB
--- 1861,1867
},
{
! {"log_temp_files", PGC_SUSET, LOGGING_WHAT,
gettext_noop("Log the use of temporary files larger than this number of kilobytes."),
gettext_noop("Zero logs all files. The default is -1 (turning this feature off)."),
GUC_UNIT_KB
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
