Re: [pgsql-patches] guid/uuid datatype
Jim Nasby wrote: Following that logic we should remove all data types that aren't specified in ANSI. Sure, if we were to arrive at some acceptable implementation of official modules, that would make sense in some cases. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] Getting rid of warnings
On Thu, Jan 25, 2007 at 08:56:27PM +0100, Magnus Hagander wrote:
Bruce Momjian wrote:
I need an updated version of this to apply. The suggested changes are
too extensive.
I'll try to do this tomorrow. If I get it right, the changes needed are:
NULL instead of cast of function ptr, per Peter.
Do the const-change in the other direction in contrib/intarray.
The patch never contained anything for those const ** warnings, so I'll
just continue not to include those.
Ok, here's an updated patch per this.
//Magnus
Index: contrib/intarray/_int.h
===
RCS file: /projects/cvsroot/pgsql/contrib/intarray/_int.h,v
retrieving revision 1.11
diff -c -r1.11 _int.h
*** contrib/intarray/_int.h 4 Oct 2006 00:29:45 - 1.11
--- contrib/intarray/_int.h 26 Jan 2007 11:48:20 -
***
*** 108,114
/*
** useful function
*/
! bool isort(int4 *a, const int len);
ArrayType *new_intArrayType(int num);
ArrayType *copy_intArrayType(ArrayType *a);
ArrayType *resize_intArrayType(ArrayType *a, int num);
--- 108,114
/*
** useful function
*/
! bool isort(int4 *a, int len);
ArrayType *new_intArrayType(int num);
ArrayType *copy_intArrayType(ArrayType *a);
ArrayType *resize_intArrayType(ArrayType *a, int num);
Index: contrib/pg_trgm/trgm_op.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pg_trgm/trgm_op.c,v
retrieving revision 1.5
diff -c -r1.5 trgm_op.c
*** contrib/pg_trgm/trgm_op.c 30 May 2006 22:12:13 - 1.5
--- contrib/pg_trgm/trgm_op.c 25 Jan 2007 12:18:05 -
***
*** 5,11
PG_MODULE_MAGIC;
! float4trgm_limit = 0.3;
PG_FUNCTION_INFO_V1(set_limit);
Datum set_limit(PG_FUNCTION_ARGS);
--- 5,11
PG_MODULE_MAGIC;
! float4trgm_limit = 0.3f;
PG_FUNCTION_INFO_V1(set_limit);
Datum set_limit(PG_FUNCTION_ARGS);
Index: contrib/tsearch2/rank.c
===
RCS file: /projects/cvsroot/pgsql/contrib/tsearch2/rank.c,v
retrieving revision 1.21
diff -c -r1.21 rank.c
*** contrib/tsearch2/rank.c 28 Dec 2006 01:09:01 - 1.21
--- contrib/tsearch2/rank.c 25 Jan 2007 12:19:30 -
***
*** 37,43
PG_FUNCTION_INFO_V1(get_covers);
Datum get_covers(PG_FUNCTION_ARGS);
! static float weights[] = {0.1, 0.2, 0.4, 1.0};
#define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )
--- 37,43
PG_FUNCTION_INFO_V1(get_covers);
Datum get_covers(PG_FUNCTION_ARGS);
! static float weights[] = {0.1f, 0.2f, 0.4f, 1.0f};
#define wpos(wep) ( w[ WEP_GETWEIGHT(wep) ] )
***
*** 59,65
word_distance(int4 w)
{
if (w 100)
! return 1e-30;
return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
}
--- 59,65
word_distance(int4 w)
{
if (w 100)
! return (float4)1e-30;
return 1.0 / (1.005 + 0.05 * exp(((float4) w) / 1.5 - 2));
}
***
*** 331,337
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);
if (res 0)
! res = 1e-20;
if ((method RANK_NORM_LOGLENGTH) t-size 0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
--- 331,337
calc_rank_and(w, t, q) : calc_rank_or(w, t, q);
if (res 0)
! res = (float)1e-20;
if ((method RANK_NORM_LOGLENGTH) t-size 0)
res /= log((double) (cnt_length(t) + 1)) / log(2.0);
Index: src/include/pg_config.h.win32
===
RCS file: /projects/cvsroot/pgsql/src/include/pg_config.h.win32,v
retrieving revision 1.39
diff -c -r1.39 pg_config.h.win32
*** src/include/pg_config.h.win32 5 Jan 2007 20:54:39 - 1.39
--- src/include/pg_config.h.win32 25 Jan 2007 13:10:02 -
***
*** 366,372
--- 366,374
#define HAVE_STRDUP 1
/* Define to 1 if you have the `strerror' function. */
+ #ifndef HAVE_STRERROR
#define HAVE_STRERROR 1
+ #endif
/* Define to 1 if you have the `strerror_r' function. */
/* #undef HAVE_STRERROR_R */
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.90
diff -c -r1.90 fe-secure.c
*** src/interfaces/libpq/fe-secure.c5 Jan 2007 22:20:01 - 1.90
--- src/interfaces/libpq/fe-secure.c25 Jan 2007 14:39:23 -
***
*** 575,581
charfnbuf[MAXPGPATH];
FILE *fp;
PGconn *conn = (PGconn *) SSL_get_app_data(ssl);
- int (*cb) () = NULL;/* how to read user
password */
char
[pgsql-patches] uuid patch 3.0 (8.3devel)
Folks,
As commented by Peter, I have done some re-styling.
Some additional tests and format checking have been added to this patch.
Put your file at the end of the OBJS variable (or in some sort of
sensible order).
Done.
Put your file at the end of the tests (or in some sort of sensible
order).
Done.
Refrain from self-evident comments, such as
+ /*
+ * function handles input for the uuid datatype
+ */
+ Datum uuid_in(PG_FUNCTION_ARGS)
You can probably delete all comments in your patch by that criterion.
Some changed, but not all has been removed for readability reasons.
This sort of super-verbose coding might be alright, but it gets tiring
when done systematically for no reason:
+ result = DirectFunctionCall1(textin, uuid_str);
+ return result;
Some changed, but not all.
The uuid.c file claims it is uuid.h.
Changed.
Move the stuff from builtins.h to uuid.h.
Not changed. please see:
http://archives.postgresql.org/pgsql-patches/2007-01/msg00362.php
Move the stuff from uuid.h that is not needed anywhere else to uuid.c.
Done.
No // comments.
Done.
Don't number the tests. We might want to insert something later and
that would mess everything up.
Done.
Capitalize the SQL test scripts as in other files.
Done.
Remove gratuitous whitespace changes (there are many).
Done. AFAICS
Also remove the whitespace at the end of lines.
Done. AFAICS
Make some reasonable effort to align the catalog entries for
readability.
Done.
Any more comments?
Regards,
Gevik.
###
# Patch created by PostgreSQL Patch Generator 1.0
# Written by Gevik Babakhani 2007 (BSD)
#
# Apply this patch:
# cd ./mydir.../pgsql/
# patch -p0 this.patch.file.diff
#
# Date created: Fri, 26 Jan 2007 12:55:29 +0100
#
# New files:
#./src/backend/utils/adt/uuid.c
#./src/include/utils/uuid.h
#./src/test/regress/expected/uuid.out
#./src/test/regress/sql/uuid.sql
# Modified files:
#./src/backend/utils/adt/Makefile
#./src/include/catalog/pg_amop.h
#./src/include/catalog/pg_amproc.h
#./src/include/catalog/pg_cast.h
#./src/include/catalog/pg_opclass.h
#./src/include/catalog/pg_operator.h
#./src/include/catalog/pg_opfamily.h
#./src/include/catalog/pg_proc.h
#./src/include/catalog/pg_type.h
#./src/include/utils/builtins.h
#./src/test/regress/parallel_schedule
#./src/test/regress/serial_schedule
##
*** ./src/backend/utils/adt/Makefile.orig 2007-01-24 16:35:05.0 +0100
--- ./src/backend/utils/adt/Makefile 2007-01-26 08:12:27.0 +0100
***
*** 25,31
tid.o timestamp.o varbit.o varchar.o varlena.o version.o xid.o \
network.o mac.o inet_net_ntop.o inet_net_pton.o \
ri_triggers.o pg_lzcompress.o pg_locale.o formatting.o \
! ascii.o quote.o pgstatfuncs.o encode.o dbsize.o genfile.o xml.o
like.o: like.c like_match.c
--- 25,32
tid.o timestamp.o varbit.o varchar.o varlena.o version.o xid.o \
network.o mac.o inet_net_ntop.o inet_net_pton.o \
ri_triggers.o pg_lzcompress.o pg_locale.o formatting.o \
! ascii.o quote.o pgstatfuncs.o encode.o dbsize.o genfile.o xml.o \
! uuid.o
like.o: like.c like_match.c
*** ./src/backend/utils/adt/uuid.c.orig 1970-01-01 01:00:00.0 +0100
--- ./src/backend/utils/adt/uuid.c 2007-01-26 11:25:12.0 +0100
***
*** 0
--- 1,298
+ /*-
+ *
+ * uuid.c
+ * Functions for the built-in type uuid.
+ *
+ * Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
+ * Portions Copyright (c) 1994, Regents of the University of California
+ *
+ *-
+ */
+
+ #include postgres.h
+ #include access/hash.h
+ #include libpq/pqformat.h
+ #include utils/builtins.h
+ #include utils/uuid.h
+
+ /* Accepted GUID formats */
+
+ /* this one is the default output format */
+ #define UUID_FMT1 %02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx
+ #define UUID_FMT2 {%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx}
+ #define UUID_FMT3 %02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx
+
+ /* these are uuid styles coresponding to above to check the actual uuid string
+ for format validity */
+ #define UUID_CHK_FMT1 ----
+ #define UUID_CHK_FMT2 {----}
+ #define UUID_CHK_FMT3
+
+ /* output length */
+ #define
Re: [pgsql-patches] pg_dump pretty_print
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Peter Eisentraut replied: The harm here is that under undefined circumstances a dump file will not be a proper and robust representation of the original database, which would add significant confusion and potential for error. What undefined circumstances are we talking here? If there is a chance that pg_get_viewdef and company do not output a version that can be read again by the database because we simply changed the whitespace, that sounds like a serious bug to be fixed, not a reason to reject this optional flag. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200701251003 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFFuXd2vJuQZxSWSsgRA9VDAJ9S1b+4DJomO3Bmij4wvida9wtgfgCeID16 qeoNrrehtTGIeJeL8T+mx9M= =VecV -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[pgsql-patches] Docs improvements
1) mvcc.sgml.patch Update comments about installation of DocBook on FreeBSD. DocBook v4.2 is present in ports now. 2) docguide.sgml.patch Table of compatibility of table-lock modes. IMHO, it's useful, clear for understanding. Text view of the table is: | AS | RS | RE | SUE | S | SRE | E | AE | +---+---+---+---+---+---+---+---+ AS | O | O | O | O | O | O | O | X | +---+---+---+---+---+---+---+---+ RS | O | O | O | O | O | O | X | X | +---+---+---+---+---+---+---+---+ RE | O | O | O | O | X | X | X | X | +---+---+---+---+---+---+---+---+ SUE | O | O | O | X | X | X | X | X | +---+---+---+---+---+---+---+---+ S | O | O | X | X | O | X | X | X | +---+---+---+---+---+---+---+---+ SRE | O | O | X | X | X | X | X | X | +---+---+---+---+---+---+---+---+ E | O | X | X | X | X | X | X | X | +---+---+---+---+---+---+---+---+ AE | X | X | X | X | X | X | X | X | +---+---+---+---+---+---+---+---+ Upper row and left column contain abbreviation of lock modes by the first characters( AS - ACCESS SHARE ) -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ *** mvcc.sgml.orig Fri Jan 26 16:27:27 2007 --- mvcc.sgml Fri Jan 26 17:49:29 2007 *** *** 741,746 --- 741,863 releases locks acquired within it. /para + table tocentry=1 id=table-lock-compatibility + title Compatibility of lock modes/title + tgroup cols=9 + colspec colnum=1 colwidth=1* + colspec colnum=2 colwidth=1* + colspec colnum=3 colwidth=1* + colspec colnum=4 colwidth=1* + colspec colnum=5 colwidth=1* + colspec colnum=6 colwidth=1* + colspec colnum=7 colwidth=1* + colspec colnum=8 colwidth=1* + colspec colnum=9 colwidth=1* + thead + row + entryModes/entry + entryAS/entry + entryRS/entry + entryRE/entry + entrySUE/entry + entryS/entry + entrySRE/entry + entryE/entry + entryAE/entry + /row + /thead + tbody + row + entryAS/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerN/entry + /row + row + entryRS/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerN/entry + entry align=centerN/entry + /row + row + entryRE/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + /row + row + entrySUE/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + /row + row + entryS/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerY/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + /row + row + entrySRE/entry + entry align=centerY/entry + entry align=centerY/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + /row + row + entryE/entry + entry align=centerY/entry + entry align=centerN/entry + entry align=centerN/entry + entry align=centerN/entry + entry
Re: [HACKERS] [pgsql-patches] pg_dump pretty_print
Greg Sabino Mullane [EMAIL PROTECTED] writes: Peter Eisentraut replied: The harm here is that under undefined circumstances a dump file will not be a proper and robust representation of the original database, which would add significant confusion and potential for error. What undefined circumstances are we talking here? If there is a chance that pg_get_viewdef and company do not output a version that can be read again by the database because we simply changed the whitespace, that sounds like a serious bug to be fixed, not a reason to reject this optional flag. The original definition of the prettyprint flag was that it'd produce a version that was nice to look at but not guaranteed to parse back exactly the same; in particular it might omit parentheses that perhaps were really needed to ensure the same parsing. (I think there might be some other issues too ... but whitespace is NOT one of them.) It's possible that the current prettyprint code is smart enough to never make such an error --- and then again it's possible that it isn't. Like Peter, I've not got much confidence in that code, and don't want to trust pg_dump's correctness to it. regards, tom lane ---(end of broadcast)--- TIP 1: 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: [pgsql-patches] Getting rid of warnings
On Fri, 2007-01-26 at 12:53 +0100, Magnus Hagander wrote: Ok, here's an updated patch per this. Applied -- thanks for the patch. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
[pgsql-patches] scrollable cursor support for plpgsql
Hello this patch contains ansi sql scrollable cursors's support for plpgsql. Add three function to SPI and plpgsql scrollable cursor sup. is first test app of this functionality. Regards Pavel Stehule _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ *** ./doc/src/sgml/plpgsql.sgml.orig 2007-01-26 20:30:17.0 +0100 --- ./doc/src/sgml/plpgsql.sgml 2007-01-26 21:33:38.0 +0100 *** *** 2354,2360 internally to avoid memory problems.) A more interesting usage is to return a reference to a cursor that a function has created, allowing the caller to read the rows. This provides an efficient way to return ! large row sets from functions. /para sect2 id=plpgsql-cursor-declarations --- 2354,2361 internally to avoid memory problems.) A more interesting usage is to return a reference to a cursor that a function has created, allowing the caller to read the rows. This provides an efficient way to return ! large row sets from functions. PL/pgSQL allows to use scrollable ! cursors. /para sect2 id=plpgsql-cursor-declarations *** *** 2368,2374 Another way is to use the cursor declaration syntax, which in general is: synopsis ! replaceablename/replaceable CURSOR optional ( replaceablearguments/replaceable ) /optional FOR replaceablequery/replaceable; /synopsis (literalFOR/ may be replaced by literalIS/ for productnameOracle/productname compatibility.) --- 2369,2375 Another way is to use the cursor declaration syntax, which in general is: synopsis ! replaceablename/replaceable optional optional NO /optional SCROLL /optional CURSOR optional ( replaceablearguments/replaceable ) /optional FOR replaceablequery/replaceable; /synopsis (literalFOR/ may be replaced by literalIS/ for productnameOracle/productname compatibility.) *** *** 2517,2523 titleliteralFETCH//title synopsis ! FETCH replaceablecursor/replaceable INTO replaceabletarget/replaceable; /synopsis para --- 2518,2524 titleliteralFETCH//title synopsis ! FETCH optional replaceabledirection/replaceable FROM /optional replaceablecursor/replaceable INTO replaceabletarget/replaceable; /synopsis para *** *** 2526,2539 variable, or a comma-separated list of simple variables, just like commandSELECT INTO/command. As with commandSELECT INTO/command, the special variable literalFOUND/literal may ! be checked to see whether a row was obtained or not. /para - para An example: programlisting FETCH curs1 INTO rowvar; FETCH curs2 INTO foo, bar, baz; /programlisting /para /sect3 --- 2527,2545 variable, or a comma-separated list of simple variables, just like commandSELECT INTO/command. As with commandSELECT INTO/command, the special variable literalFOUND/literal may ! be checked to see whether a row was obtained or not. More details ! about replaceabledirection/replaceable you can find in ! xref linkend=sql-fetch without literalBACKWARD/ and literalFORWARD/ keywords. ! Statement commandFETCH/command in applicationPL/pgSQL/ returns only one ! or zero row every time. /para para An example: programlisting FETCH curs1 INTO rowvar; FETCH curs2 INTO foo, bar, baz; + FETCH LAST INTO x, y; + FETCH RELATIVE -2 INTO x; /programlisting /para /sect3 *** ./doc/src/sgml/spi.sgml.orig 2007-01-14 12:37:19.0 +0100 --- ./doc/src/sgml/spi.sgml 2007-01-26 11:46:18.0 +0100 *** *** 800,805 --- 800,937 !-- *** -- + refentry id=spi-spi-prepare-cursor + refmeta + refentrytitleSPI_prepare_cursor/refentrytitle + /refmeta + + refnamediv + refnameSPI_prepare_cursor/refname + refpurposeprepare a plan for a cursor, without executing it yet/refpurpose + /refnamediv + + indextermprimarySPI_prepare_cursor/primary/indexterm + + refsynopsisdiv + synopsis + void * SPI_prepare_cursor(const char * parametercommand/parameter, int parameternargs/parameter, Oid * parameterargtypes/parameter, int parameteroptions/parameter) + /synopsis + /refsynopsisdiv + + refsect1 + titleDescription/title + + para +functionSPI_prepare_cursor/function creates and returns an execution +plan for the specified select but doesn't execute the command. +This function should only be called from a connected procedure. This +function allows set cursor's options. + /para + + para +When the same or a similar command is to be executed repeatedly, it +may be advantageous to perform the planning only once. +
Re: [pgsql-patches] [HACKERS] less privileged pl install
On Thu, 25 Jan 2007, Jeremy Drake wrote: On Thu, 25 Jan 2007, Jeremy Drake wrote: I think that an ALTER LANGUAGE OWNER TO is the proper response to these things, and unless I hear otherwise I will attempt to add this to my patch. Here is the patch which adds this. It also allows ALTER LANGUAGE RENAME TO for the owner, which I missed before. I would appreciate someone with more knowledge of the permissions infrastructure to take a look at it since I am fairly new to it and may not fully understand its intricacies. I have refactored the owner checking of languages in the same manner as it is for other owned objects. I have changed to using standard permissions error messages (aclcheck_error) for the language permissions errors. I consider this patch ready for review, assuming the permissions rules outlined by Tom Lane on -hackers are valid. For reference, here are the rules that this patch is intended to implement: On Wed, 24 Jan 2007, Tom Lane wrote: In detail, it'd look something like: * For an untrusted language: must be superuser to either create or use the language (no change from current rules). Ownership of the pg_language entry is really irrelevant, as is its ACL. * For a trusted language: * if pg_pltemplate.something is ON: either a superuser or the current DB's owner can CREATE the language. In either case the pg_language entry will be marked as owned by the DB owner (pg_database.datdba), which means that subsequently he (or a superuser) can grant or deny USAGE within his DB. * if pg_pltemplate.something is OFF: must be superuser to CREATE the language; subsequently it will be owned by you, so only you or another superuser can grant or deny USAGE (same behavior as currently). The only difference from this is, that when superuser is required, the owner of the language is not the superuser who created it, but BOOTSTRAP_SUPERUSERID. This is because my interpretation was that the same behavior as currently took precedence. The current behavior in cvs is that languages have no owner, and for purposes where one would be needed it is assumed to be BOOTSTRAP_SUPERUSERID. Is this valid, or should I instead set the owner to GetUserId() in those cases? -- Academic politics is the most vicious and bitter form of politics, because the stakes are so low. -- Wallace SayreIndex: doc/src/sgml/ref/alter_language.sgml === RCS file: /data/local/jeremyd/postgres/cvsuproot/pgsql/doc/src/sgml/ref/alter_language.sgml,v retrieving revision 1.6 diff -c -r1.6 alter_language.sgml *** doc/src/sgml/ref/alter_language.sgml16 Sep 2006 00:30:16 - 1.6 --- doc/src/sgml/ref/alter_language.sgml26 Jan 2007 01:01:40 - *** *** 21,26 --- 21,28 refsynopsisdiv synopsis ALTER LANGUAGE replaceablename/replaceable RENAME TO replaceablenewname/replaceable + + ALTER LANGUAGE replaceablename/replaceable OWNER TO replaceablenew_owner/replaceable /synopsis /refsynopsisdiv *** *** 48,53 --- 50,64 /varlistentry varlistentry + termreplaceablenew_owner/replaceable/term + listitem + para + The new owner of the language. + /para + /listitem +/varlistentry + +varlistentry termreplaceablenewname/replaceable/term listitem para Index: src/backend/catalog/aclchk.c === RCS file: /data/local/jeremyd/postgres/cvsuproot/pgsql/src/backend/catalog/aclchk.c,v retrieving revision 1.135 diff -c -r1.135 aclchk.c *** src/backend/catalog/aclchk.c23 Jan 2007 05:07:17 - 1.135 --- src/backend/catalog/aclchk.c26 Jan 2007 23:53:03 - *** *** 1003,1013 /* * Get owner ID and working copy of existing ACL. If there's no ACL, * substitute the proper default. -* -* Note: for now, languages are treated as owned by the bootstrap -* user. We should add an owner column to pg_language instead. */ ! ownerId = BOOTSTRAP_SUPERUSERID; aclDatum = SysCacheGetAttr(LANGNAME, tuple, Anum_pg_language_lanacl, isNull); if (isNull) --- 1003,1010 /* * Get owner ID and working copy of existing ACL. If there's no ACL, * substitute the proper default. */ ! ownerId = pg_language_tuple-lanowner; aclDatum = SysCacheGetAttr(LANGNAME, tuple, Anum_pg_language_lanacl, isNull); if (isNull) *** *** 1770,1777 (errcode(ERRCODE_UNDEFINED_OBJECT),
Re: [pgsql-patches] Autovacuum launcher patch
Alvaro Herrera [EMAIL PROTECTED] writes: The launcher is a dummy process; it never connects to any database. ... Eventually this will need to be changed so that the launcher tells the worker exactly what table to work on. I detect a certain lack of clarity of thinking here. Either the launcher can read databases or it can't. Do you intend to solve the problem of all the transaction/catcache infrastructure being designed on the assumption of being in exactly one database? I'd suggest sticking to something closer to the current two-phase design where you make some preliminary decision which database to send a worker to, and then the worker determines exactly what to do once it can look around inside the DB. Possibly we need some back-signaling mechanism whereby a worker can tell the launcher hey boss, send help if it sees that there are enough tables that need work, but I'm unenthused about having the launcher figure that out itself. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[pgsql-patches] Ctid chain following enhancement
Attached is a patch which should marginally improve the ctid chain followin code path when current and the next tuple in the chain are in the same block. In the current code, we unconditionally drop pin of the current block without checking whether the next tuple is the same block or not. ISTM that this can be improved. The attached patch replaces the heap_fetch() with heap_release_fetch() in EvalPlanQual() and thus releases the buffer iff the chain gets into a different block. Similarly, ReadBuffer() is replaced with ReleaseAndReadBuffer() in heap_get_latest_tid() for the same reason. The buffer is set to InvalidBuffer to start with and is not released at the end of the loop. heap_release_fetch()/ ReleaseAndReadBuffer() would release it if required. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com cf-enhance-head.patch Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] less privileged pl install
Jeremy Drake [EMAIL PROTECTED] writes: The only difference from this is, that when superuser is required, the owner of the language is not the superuser who created it, but BOOTSTRAP_SUPERUSERID. This is because my interpretation was that the same behavior as currently took precedence. The current behavior in cvs is that languages have no owner, and for purposes where one would be needed it is assumed to be BOOTSTRAP_SUPERUSERID. Is this valid, or should I instead set the owner to GetUserId() in those cases? I'd go with GetUserId() in the cases where you're not explicitly assigning ownership to the datdba role. AFAIR the assumption that languages are owned by BOOTSTRAP_SUPERUSERID was just a kluge to use in some bits of code that had to have a notion of a specific owner. Now in reality every superuser has the same privileges as every other one, and so it doesn't matter much which one you use, but we might as well record who actually did the deed. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [HACKERS] less privileged pl install
On Sat, 27 Jan 2007, Tom Lane wrote:
I'd go with GetUserId() in the cases where you're not explicitly
assigning ownership to the datdba role. AFAIR the assumption that
languages are owned by BOOTSTRAP_SUPERUSERID was just a kluge to use in
some bits of code that had to have a notion of a specific owner. Now
in reality every superuser has the same privileges as every other one,
and so it doesn't matter much which one you use, but we might as well
record who actually did the deed.
Here is a version of the patch which does this. Very minor change from
the last version...
--
Begathon, n.:
A multi-day event on public television, used to raise money so
you won't have to watch commercials.Index: doc/src/sgml/ref/alter_language.sgml
===
RCS file:
/data/local/jeremyd/postgres/cvsuproot/pgsql/doc/src/sgml/ref/alter_language.sgml,v
retrieving revision 1.6
diff -c -r1.6 alter_language.sgml
*** doc/src/sgml/ref/alter_language.sgml16 Sep 2006 00:30:16 -
1.6
--- doc/src/sgml/ref/alter_language.sgml26 Jan 2007 01:01:40 -
***
*** 21,26
--- 21,28
refsynopsisdiv
synopsis
ALTER LANGUAGE replaceablename/replaceable RENAME TO
replaceablenewname/replaceable
+
+ ALTER LANGUAGE replaceablename/replaceable OWNER TO
replaceablenew_owner/replaceable
/synopsis
/refsynopsisdiv
***
*** 48,53
--- 50,64
/varlistentry
varlistentry
+ termreplaceablenew_owner/replaceable/term
+ listitem
+ para
+ The new owner of the language.
+ /para
+ /listitem
+/varlistentry
+
+varlistentry
termreplaceablenewname/replaceable/term
listitem
para
Index: src/backend/catalog/aclchk.c
===
RCS file:
/data/local/jeremyd/postgres/cvsuproot/pgsql/src/backend/catalog/aclchk.c,v
retrieving revision 1.135
diff -c -r1.135 aclchk.c
*** src/backend/catalog/aclchk.c23 Jan 2007 05:07:17 - 1.135
--- src/backend/catalog/aclchk.c26 Jan 2007 23:53:03 -
***
*** 1003,1013
/*
* Get owner ID and working copy of existing ACL. If there's no
ACL,
* substitute the proper default.
-*
-* Note: for now, languages are treated as owned by the
bootstrap
-* user. We should add an owner column to pg_language instead.
*/
! ownerId = BOOTSTRAP_SUPERUSERID;
aclDatum = SysCacheGetAttr(LANGNAME, tuple,
Anum_pg_language_lanacl,
isNull);
if (isNull)
--- 1003,1010
/*
* Get owner ID and working copy of existing ACL. If there's no
ACL,
* substitute the proper default.
*/
! ownerId = pg_language_tuple-lanowner;
aclDatum = SysCacheGetAttr(LANGNAME, tuple,
Anum_pg_language_lanacl,
isNull);
if (isNull)
***
*** 1770,1777
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg(language with OID %u does not exist,
lang_oid)));
! /* XXX pg_language should have an owner column, but doesn't */
! ownerId = BOOTSTRAP_SUPERUSERID;
aclDatum = SysCacheGetAttr(LANGOID, tuple, Anum_pg_language_lanacl,
isNull);
--- 1767,1773
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg(language with OID %u does not exist,
lang_oid)));
! ownerId = ((Form_pg_language) GETSTRUCT(tuple))-lanowner;
aclDatum = SysCacheGetAttr(LANGOID, tuple, Anum_pg_language_lanacl,
isNull);
***
*** 2148,2153
--- 2144,2177
}
/*
+ * Ownership check for a procedural language (specified by OID)
+ */
+ bool
+ pg_language_ownercheck(Oid lan_oid, Oid roleid)
+ {
+ HeapTuple tuple;
+ Oid ownerId;
+
+ /* Superusers bypass all permission checking. */
+ if (superuser_arg(roleid))
+ return true;
+
+ tuple = SearchSysCache(LANGOID,
+ ObjectIdGetDatum(lan_oid),
+ 0, 0, 0);
+ if (!HeapTupleIsValid(tuple))
+ ereport(ERROR,
+ (errcode(ERRCODE_UNDEFINED_FUNCTION),
+errmsg(language with OID %u does not exist,
lan_oid)));
+
+ ownerId = ((Form_pg_language) GETSTRUCT(tuple))-lanowner;
+
+ ReleaseSysCache(tuple);
+
+
