[PATCHES] Add chklocale.c to msvc build
Hi, attached patch adds chklocale.c to pgportfiles in Mkvcbuild perl module (not really worth the .diff :)) This fixes MSVC build (see buildfarm errors with unresolved reference for _pg_get_encoding_from_locale). -- Regards Petr Jelinek (PJMODOS) Index: Mkvcbuild.pm === RCS file: /projects/cvsroot/pgsql/src/tools/msvc/Mkvcbuild.pm,v retrieving revision 1.17 diff -c -r1.17 Mkvcbuild.pm *** Mkvcbuild.pm27 Sep 2007 19:53:44 - 1.17 --- Mkvcbuild.pm29 Sep 2007 05:28:16 - *** *** 44,50 our @pgportfiles = qw( crypt.c fseeko.c getrusage.c inet_aton.c random.c srandom.c ! unsetenv.c getaddrinfo.c gettimeofday.c kill.c open.c rand.c snprintf.c strlcat.c strlcpy.c copydir.c dirmod.c exec.c noblock.c path.c pipe.c pgsleep.c pgstrcasecmp.c qsort.c qsort_arg.c sprompt.c thread.c getopt.c getopt_long.c dirent.c rint.c win32error.c); --- 44,50 our @pgportfiles = qw( crypt.c fseeko.c getrusage.c inet_aton.c random.c srandom.c ! unsetenv.c getaddrinfo.c gettimeofday.c chklocale.c kill.c open.c rand.c snprintf.c strlcat.c strlcpy.c copydir.c dirmod.c exec.c noblock.c path.c pipe.c pgsleep.c pgstrcasecmp.c qsort.c qsort_arg.c sprompt.c thread.c getopt.c getopt_long.c dirent.c rint.c win32error.c); ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] ALTER TYPE RENAME
Hi,
I noticed we don't have ALTER TYPE foo RENAME TO bar command which would
be handy for me especially for enum types.
So I wrote this little patch (including very brief doc) which adds above
syntax. It basically just does some checks and calls existing TypeRename
function which is used for renaming table rowtype now.
I hope I haven't missed anything, but I am unsure about two things.
First, this patch allows renaming base types which I don't know if it's
desired. And second we might want to throw error when renaming rowtype
(there is check in AlterTypeOwner for this but not in AlterTypeNamespace
so I don't know).
--
Regards
Petr Jelinek (PJMODOS)
Index: doc/src/sgml/ref/alter_type.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/alter_type.sgml,v
retrieving revision 1.4
diff -c -r1.4 alter_type.sgml
*** doc/src/sgml/ref/alter_type.sgml16 Sep 2006 00:30:16 - 1.4
--- doc/src/sgml/ref/alter_type.sgml29 Sep 2007 05:43:14 -
***
*** 26,31
--- 26,32
synopsis
ALTER TYPE replaceable class=PARAMETERname/replaceable OWNER TO
replaceable class=PARAMETERnew_owner/replaceable
ALTER TYPE replaceable class=PARAMETERname/replaceable SET SCHEMA
replaceable class=PARAMETERnew_schema/replaceable
+ ALTER TYPE replaceable class=PARAMETERname/replaceable RENAME TO
replaceable class=PARAMETERnew_name/replaceable
/synopsis
/refsynopsisdiv
***
*** 83,88
--- 84,98
/listitem
/varlistentry
+ varlistentry
+ termreplaceable class=PARAMETERnew_name/replaceable/term
+ listitem
+para
+ The new name for the type.
+/para
+ /listitem
+ /varlistentry
+
/variablelist
/para
/refsect1
Index: src/backend/commands/alter.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/alter.c,v
retrieving revision 1.25
diff -c -r1.25 alter.c
*** src/backend/commands/alter.c21 Aug 2007 01:11:14 - 1.25
--- src/backend/commands/alter.c29 Sep 2007 05:12:31 -
***
*** 154,159
--- 154,164
RenameTSConfiguration(stmt-object, stmt-newname);
break;
+ case OBJECT_TYPE:
+ case OBJECT_DOMAIN:
+ RenameType(stmt-object, stmt-newname);
+ break;
+
default:
elog(ERROR, unrecognized rename stmt type: %d,
(int) stmt-renameType);
Index: src/backend/commands/typecmds.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/typecmds.c,v
retrieving revision 1.107
diff -c -r1.107 typecmds.c
*** src/backend/commands/typecmds.c 4 Sep 2007 16:41:42 - 1.107
--- src/backend/commands/typecmds.c 29 Sep 2007 05:11:22 -
***
*** 2514,2519
--- 2514,2567
}
/*
+ * Execute ALTER TYPE RENAME
+ */
+ void
+ RenameType(List *names, const char *newTypeName)
+ {
+ TypeName *typename;
+ Oid typeOid;
+ Relationrel;
+ HeapTuple tup;
+ Form_pg_type typTup;
+
+ /* Make a TypeName so we can use standard type lookup machinery */
+ typename = makeTypeNameFromNameList(names);
+ typeOid = typenameTypeId(NULL, typename);
+
+ /* Look up the type in the type table */
+ rel = heap_open(TypeRelationId, RowExclusiveLock);
+
+ tup = SearchSysCacheCopy(TYPEOID,
+
ObjectIdGetDatum(typeOid),
+0, 0, 0);
+ if (!HeapTupleIsValid(tup))
+ elog(ERROR, cache lookup failed for type %u, typeOid);
+ typTup = (Form_pg_type) GETSTRUCT(tup);
+
+ /* check permissions on type */
+ if (!pg_type_ownercheck(typeOid, GetUserId()))
+ aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_TYPE,
+ format_type_be(typeOid));
+
+ /* don't allow direct alteration of array types */
+ if (OidIsValid(typTup-typelem)
+ get_array_type(typTup-typelem) == typeOid)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+errmsg(cannot alter array type %s,
+ format_type_be(typeOid)),
+errhint(You can alter type %s, which will
alter the array type as well.,
+
format_type_be(typTup-typelem;
+
+ /* and do the work */
+ TypeRename(typeOid, newTypeName, typTup-typnamespace);
+
+ /* Clean up */
+ heap_close(rel,
Re: [PATCHES] Add chklocale.c to msvc build
Petr Jelinek wrote: Hi, attached patch adds chklocale.c to pgportfiles in Mkvcbuild perl module (not really worth the .diff :)) This fixes MSVC build (see buildfarm errors with unresolved reference for _pg_get_encoding_from_locale). Similar patch applied. I put the chklocale.c file in pseudo alphabtical order. I say pseudo because I think I originally planned to have them alphabetically, but I've obviously broken that many times before :-) //Magnus ---(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: [PATCHES] OpenSSL Applink
--- Original Message --- From: Tom Lane [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 29/09/07, 01:28:09 Subject: Re: [PATCHES] OpenSSL Applink I concur with Magnus that it'll be better if there's not two code paths here. It's not entirely clear whether BIO_new_fp() would avoid the problematic calls, but it doesn't look like it'd be hard to try. The last version of the patch I posted uses BIO_new_file() in all cases, and (from memory) BIO_get_fp() in the non-win32 case to get a FILE* to pass to fstat. I believe the problem is sharing FILE*'s between differing runtime versions used by openssl and the app. Coding it with BIO_new_file makes it less tempting for future changes to start mucking about with FILE*'s on Windows. Note that I've been away from my *nix boxes so I haven't tested the patch except on Windows yet. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] set_ps_display during recovery
Small patch to set ps display during recovery, so we can see the current
WAL file being processed in both crash and archive recovery.
Very simple patch, but useful. Tested.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
Index: src/backend/access/transam/xlog.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.282
diff -c -r1.282 xlog.c
*** src/backend/access/transam/xlog.c 26 Sep 2007 22:36:30 - 1.282
--- src/backend/access/transam/xlog.c 29 Sep 2007 07:51:20 -
***
*** 48,53
--- 48,54
#include storage/spin.h
#include utils/builtins.h
#include utils/pg_locale.h
+ #include utils/ps_status.h
***
*** 2296,2310
if (tli curFileTLI)
break;/* don't bother looking at too-old TLIs */
if (InArchiveRecovery)
- {
- XLogFileName(xlogfname, tli, log, seg);
restoredFromArchive = RestoreArchivedFile(path, xlogfname,
RECOVERYXLOG,
XLogSegSize);
- }
else
XLogFilePath(path, tli, log, seg);
fd = BasicOpenFile(path, O_RDONLY | PG_BINARY, 0);
if (fd = 0)
--- 2297,2310
if (tli curFileTLI)
break;/* don't bother looking at too-old TLIs */
+ XLogFileName(xlogfname, tli, log, seg);
if (InArchiveRecovery)
restoredFromArchive = RestoreArchivedFile(path, xlogfname,
RECOVERYXLOG,
XLogSegSize);
else
XLogFilePath(path, tli, log, seg);
+ set_ps_display(xlogfname, false);
fd = BasicOpenFile(path, O_RDONLY | PG_BINARY, 0);
if (fd = 0)
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [PATCHES] OpenSSL Applink
Dave Page [EMAIL PROTECTED] writes: From: Tom Lane [EMAIL PROTECTED] ... It's not entirely clear whether BIO_new_fp() would avoid the problematic calls, but it doesn't look like it'd be hard to try. The last version of the patch I posted uses BIO_new_file() in all cases, and (from memory) BIO_get_fp() in the non-win32 case to get a FILE* to pass to fstat. Did you manage to get rid of the bogus-error-message problem that afflicted the first version of the patch? If so, this way is fine. If not, keeping control of file-opening in our own hands might be a way to dodge that. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Marko Kreen wrote: solaris openssl refuses to handle keys longer than 128bits. * aes will crash on longer keys * blowfish will silently cut the key which can result data corruption to fix it: - test errors from AES functions - bf errors cannot be tested, do test encryption - change aes compat macros to static function so they can return values Tested on Solaris Nevada and works fine. More general appriaches that also fix the problems are: - test all ciphers on first use and test fails then disable completely. This is nice as it could detect much braded range of errors. Problem with this approach is that its too big overhead for small gain, as it cannot still 100% guarantee that everything is working correctly. - Use EVP functions for encryption as they have better error handling. So crippled openssl can report via regular means that something is not supported. +1 for EVP solution. Thank you very much Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Tom Lane wrote: Marko Kreen [EMAIL PROTECTED] writes: solaris openssl refuses to handle keys longer than 128bits. ... So something like the current patch should be still applied as a near-term fix. Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. Thanks Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane wrote: Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. OK, applied to 8.1 too. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ALTER TYPE RENAME
I wrote: Hm, it's definitely a bug/oversight that AlterTypeNamespace doesn't make a similar test for that. On closer look, there *is* such a test, but it's down inside AlterTypeNamespaceInternal. 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: [PATCHES] ALTER TYPE RENAME
BTW, another issue this brings up is whether we should reject regression=# create type footyp as (f2 int); CREATE TYPE regression=# alter table footyp rename to foobar; ALTER TABLE Currently, since there's no ALTER TYPE RENAME command, this is useful functionality and I wouldn't want to forbid it. But if we provide ALTER TYPE RENAME then consistency would suggest requiring people to use that for composite types. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] set_ps_display during recovery
Simon Riggs [EMAIL PROTECTED] writes: Small patch to set ps display during recovery, so we can see the current WAL file being processed in both crash and archive recovery. Hmm, not right there, because we don't know that the file actually exists yet. Applied with modifications ... regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] OpenSSL Applink
Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: From: Tom Lane [EMAIL PROTECTED] ... It's not entirely clear whether BIO_new_fp() would avoid the problematic calls, but it doesn't look like it'd be hard to try. The last version of the patch I posted uses BIO_new_file() in all cases, and (from memory) BIO_get_fp() in the non-win32 case to get a FILE* to pass to fstat. Did you manage to get rid of the bogus-error-message problem that afflicted the first version of the patch? If so, this way is fine. No, thats still an issue. If not, keeping control of file-opening in our own hands might be a way to dodge that. That doesn't work because we still end up passing FILE pointers between potentially differing runtime builds/versions) which OpenSSL then detects and bleats about including OPENSSL_Applink(). /D ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ALTER TYPE RENAME
Tom Lane wrote: BTW, another issue this brings up is whether we should reject regression=# create type footyp as (f2 int); CREATE TYPE regression=# alter table footyp rename to foobar; ALTER TABLE Currently, since there's no ALTER TYPE RENAME command, this is useful functionality and I wouldn't want to forbid it. But if we provide ALTER TYPE RENAME then consistency would suggest requiring people to use that for composite types. I assume ALTER TYPE RENAME should rename associated relation too, then. -- Regards Petr Jelinek (PJMODOS) ---(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: [PATCHES] pgcrypto: fix for broken solaris openssl, v03
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane wrote: Applied to HEAD and 8.2. I wasn't sure if there was interest in patching further back, or if the patch was meant to work further back. Let me know if you're not happy. PostgreSQL 8.1 is shipped with Solaris. We are interesting it to have backport in 8.1. I tested patch on 8.1.10 and Solaris nevada and works fine. OK, applied to 8.1 too. Thanks. Zdenek ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ALTER TYPE RENAME
Tom Lane wrote:
Hm, I'm not entirely sure if you got the point or not. For either
relations or composite types, there is both a pg_class entry and a
pg_type entry, and their names *must* stay in sync. We could allow
people to rename both entries using either ALTER TABLE or ALTER TYPE,
but the general consensus seems to be that ALTER TYPE should be used
for composite types and ALTER TABLE for tables/views/etc. The fact
that there's a pg_class entry for a composite type is really an
implementation detail that would best not be exposed to users, so
enforcing the use of the appropriate command seems reasonable to me.
regards, tom lane
Yes, that's exactly what I meant (my language skills are not best).
Anyway, I am sending second version of the patch. Changes are:
- renamed TypeRename function to RenameTypeInternal and changed its
header comment
- throw error when using ALTER TYPE to rename rowtype
- split function renamerel to RenameRelation and RenameRelationInternal
where RenameRelation does permission checks and stuff and also checks if
it's not used for composite types and RenameRelationInternal does the
actual rename. And I also did a little cleanup in those functions
(removed unused code and changed some hardcoded relkind types to globaly
predefined constants)
- RenameType now calls RenameRelationInternal for composite types
(which calls RenameTypeInternal automatically)
Any other comments ?
--
Regards
Petr Jelinek (PJMODOS)
Index: doc/src/sgml/ref/alter_type.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/alter_type.sgml,v
retrieving revision 1.4
diff -c -r1.4 alter_type.sgml
*** doc/src/sgml/ref/alter_type.sgml16 Sep 2006 00:30:16 - 1.4
--- doc/src/sgml/ref/alter_type.sgml29 Sep 2007 05:43:14 -
***
*** 26,31
--- 26,32
synopsis
ALTER TYPE replaceable class=PARAMETERname/replaceable OWNER TO
replaceable class=PARAMETERnew_owner/replaceable
ALTER TYPE replaceable class=PARAMETERname/replaceable SET SCHEMA
replaceable class=PARAMETERnew_schema/replaceable
+ ALTER TYPE replaceable class=PARAMETERname/replaceable RNAME TO
replaceable class=PARAMETERnew_name/replaceable
/synopsis
/refsynopsisdiv
***
*** 83,88
--- 84,98
/listitem
/varlistentry
+ varlistentry
+ termreplaceable class=PARAMETERnew_name/replaceable/term
+ listitem
+para
+ The new name for the type.
+/para
+ /listitem
+ /varlistentry
+
/variablelist
/para
/refsect1
Index: src/backend/catalog/pg_type.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/catalog/pg_type.c,v
retrieving revision 1.113
diff -c -r1.113 pg_type.c
*** src/backend/catalog/pg_type.c 12 May 2007 00:54:59 - 1.113
--- src/backend/catalog/pg_type.c 30 Sep 2007 04:20:03 -
***
*** 552,566
}
/*
! * TypeRename
*This renames a type, as well as any associated array type.
*
! * Note: this isn't intended to be a user-exposed function; it doesn't check
! * permissions etc. (Perhaps TypeRenameInternal would be a better name.)
! * Currently this is only used for renaming table rowtypes.
*/
void
! TypeRename(Oid typeOid, const char *newTypeName, Oid typeNamespace)
{
Relationpg_type_desc;
HeapTuple tuple;
--- 552,567
}
/*
! * RenameTypeInternal
*This renames a type, as well as any associated array type.
*
! * Caller must have already checked privileges.
! *
! * Currently this is used for renaming table rowtypes and for
! * ALTER TYPE RENAME TO command.
*/
void
! RenameTypeInternal(Oid typeOid, const char *newTypeName, Oid typeNamespace)
{
Relationpg_type_desc;
HeapTuple tuple;
***
*** 606,612
{
char *arrname = makeArrayTypeName(newTypeName, typeNamespace);
! TypeRename(arrayOid, arrname, typeNamespace);
pfree(arrname);
}
}
--- 607,613
{
char *arrname = makeArrayTypeName(newTypeName, typeNamespace);
! RenameTypeInternal(arrayOid, arrname, typeNamespace);
pfree(arrname);
}
}
***
*** 706,712
newname = makeArrayTypeName(typeName, typeNamespace);
/* Apply the rename */
! TypeRename(typeOid, newname, typeNamespace);
/*
* We must bump the command counter so that any subsequent use of
--- 707,713
newname = makeArrayTypeName(typeName, typeNamespace);
/* Apply the rename */
! RenameTypeInternal(typeOid, newname, typeNamespace);
/*
* We must bump the command counter so that any subsequent use of
Index:
