Re: [BUGS] BUG #6239: Looking for a technical contact point for PostgreSQL compatibility issue on Windows8
On 4 October 2011 02:42, Seiko Ishida wrote: > The following bug has been logged online: > > Bug reference: 6239 > Logged by: Seiko Ishida > Email address: v-sei...@microsoft.com > PostgreSQL version: 8.2.4 > Operating system: Windows 8 > Description:Looking for a technical contact point for PostgreSQL > compatibility issue on Windows8 > Details: > > Hello, > > I am a Program Manager with the Ecosystem Engineering team at Microsoft. > > I am looking for a technical contact point to notify of compatibility issues > with PostgreSQL. > Could you please connect me to the appropriate > individual for this? > > Regards, > > Seiko Ishida > Microsoft ISV Readiness, EcoSystem Engineering Team > Program Manager > Ref : 341057 As a general check, I'd like to raise the topic of Window 8 and Windows Server 2012 support. PostgreSQL 9.2 will be released in next few weeks/months, since we are now at release candidate stage. Can I confirm that both Microsoft and PostgreSQL community thinks Windows 8/Server 2012 is fully supported? I can't see build farm members running either of those relases, and there's been no further comments on this issue here. Is somebody doing private testing on behalf of the community? Should we be mentioning Windows8 and Server 2012 support in our release notes? It seems like it could be "a feature", or at very least it will be a popular question. OTOH, we don't mention "tuned for the Linux 3 kernel", but then perhaps we should be doing that as well... -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7513: Cluster install failed
On 08/31/2012 11:49 PM, grav...@smartronix.com wrote: The following bug has been logged on the website: Bug reference: 7513 Logged by: Larry Email address: grav...@smartronix.com PostgreSQL version: 8.4.0 Operating system: win server 2003 SP2 Description: Post-Installation failed(Cluster install failed). I have gotten this error every time I have attempted to install PostgreSQL 8.4. Do you really mean 8.4.0? That has plenty of known bugs and should not ever be a new install. Download the latest in the 8.4 series, 8.4.13, from here: http://www.enterprisedb.com/products-services-training/pgdownload#windows and try again. If you still get errors, please read: http://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_Windows#Common_installation_errors and try the steps therein. If problems continue, read: http://wiki.postgresql.org/wiki/Troubleshooting_Installation and send your installer log file. Please reply to pgsql-bugs@postgresql.org not directly to me. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7512: can't install pgdg-centos91-9.1-4.noarch.rpm
Hi, On Fri, 2012-08-31 at 14:47 +, s0525...@htw-berlin.de wrote: > If I try to install Postgresql91 (in this case > postgresql91-9.1.5-1PGDG.rhel6) from > http://yum.pgrpms.org/9.1/redhat/rhel-6-x86_64/repoview/, I receive the > message that the package "centos-release" is missing. Ok, but if I try to > install "centos-release-6-3.el6.centos.9.x86_64" then, the follow error > message occurs: "file /etc/issue from install of > centos-release-6-3.el6.centos.9.x86_64 conflicts with file from package > sl-release-6.2-1.1.x86_64" (which I understand). > > Does Postgresql91 really support Scientific Linux? You started with CentOS, and now you say SL. Which one? The best way to start is here: http://yum.postgresql.org/repopackages.php#pg91 then install the relevant repo RPM based on your distro/arch. Let me know if you still have issues. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Alvaro Herrera writes: > Excerpts from Alvaro Herrera's message of vie ago 31 16:25:40 -0400 2012: >> This doesn't actually work though: it's trying to move sequences twice. >> Not sure what the right fix for this is ... still looking. > Besides being listed with deptype=extension for the extension in > question, the sequence has a deptype=auto entry for the column, which > leads to it being moved twice. Ah so. > 2. During ALTER EXTENSION execution, skip moving objects that have > already been moved. Not really sure how this would be implemented; +1 for this approach. I'm a bit surprised we didn't hit this before, because in general there can be multiple dependency chains leading from object A to object B. Most code that is doing more than trivial dependency-walking has to be prepared to cope with reaching the same object multiple times. Implementation like this seems reasonable: > 4. Maybe we could have AlterRelationNamespaceInternal check what the > current namespace is for the object, and do nothing if it's already the > target namespace. We already have some such shortcut for ALTER OWNER, IIRC, so why not for SET SCHEMA as well? I suspect that AlterRelationNamespaceInternal is not the only function that needs it, too. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Excerpts from Alvaro Herrera's message of vie ago 31 16:25:40 -0400 2012: > Excerpts from Tom Lane's message of vie ago 31 16:01:03 -0400 2012: > > Alvaro Herrera writes: > > > Here's a patch. > > > > Looks reasonable, but please try a little harder on the comments for the > > new function --- IMO it should have a header comment that explains what > > it's supposed to do exactly. > > Sure. > > This doesn't actually work though: it's trying to move sequences twice. > Not sure what the right fix for this is ... still looking. The error message: alvherre=# alter extension isn set schema foo; ERROR: tuple already updated by self Besides being listed with deptype=extension for the extension in question, the sequence has a deptype=auto entry for the column, which leads to it being moved twice. I don't see any clean fix for this: 1. At extension creation time, skip generating dependencies for sequences that are part of a table. I don't see how to do this: We would have to reach within heap_create_with_catalog and tell it not to add an deptype=extension dependency if it's called for a sequence that's part of a serial column. I don't think heap_create_with_catalog even knows that at all. 2. During ALTER EXTENSION execution, skip moving objects that have already been moved. Not really sure how this would be implemented; perhaps we could have AlterObjectNamespace_oid add each moved object to a list of moved objects, and skip everything that's already present in it. Seems very messy to implement. 3. Pass a flag to AlterTableNamespaceInternal, something like "skip_sequences", and do not call AlterSeqsNamespace it that's set. This seems really ugly though, and I'm not sure if it might break something else. 4. Maybe we could have AlterRelationNamespaceInternal check what the current namespace is for the object, and do nothing if it's already the target namespace. One thing to keep in mind is that existing databases might already have broken catalogs (i.e. extensions have already been moved and objects are already in nonexistant schemas). This is not very likely unless the user has not been using pg_dump at all. But many databases already have deptype=extension pg_depend entries for sequences owned by SERIAL columns, so it's unclear that (1) is a good solution even if it were implementable. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Excerpts from Tom Lane's message of vie ago 31 16:01:03 -0400 2012: > Alvaro Herrera writes: > > Here's a patch. > > Looks reasonable, but please try a little harder on the comments for the > new function --- IMO it should have a header comment that explains what > it's supposed to do exactly. Sure. This doesn't actually work though: it's trying to move sequences twice. Not sure what the right fix for this is ... still looking. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Alvaro Herrera writes: > Here's a patch. Looks reasonable, but please try a little harder on the comments for the new function --- IMO it should have a header comment that explains what it's supposed to do exactly. > For some reason, AlterSeqNamespaces was being passed a schema name. > This wasn't used and was not possible to keep in the patched code so I > just removed it. Probably a hangover from some previous state of the code. If it's not used I see no reason not to remove it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6758: ./configure script sets HAVE_WCSTOMBS_L 1
Andrew Hastie writes: > On 31/08/12 15:59, Tom Lane wrote: >> As a temporary workaround, you should probably just modify pg_config.h >> after configure runs, to remove the HAVE_WCSTOMBS_L symbol. > Confirm that the workaround works just fine. Now have PG 9.1.5 up and > running on AIX just fine. Thanks for checking. If you have time, perhaps you'd like to apply the committed patch: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=97395185b85b786523ee41225b53bd84c98d34f4 and confirm that all is well when using that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Excerpts from Alvaro Herrera's message of vie ago 31 12:26:50 -0400 2012: > Excerpts from Tom Lane's message of vie ago 31 12:17:59 -0400 2012: > > Alvaro Herrera writes: > > > Aha, I see the bug. It seems the split for AlterObjectNamespace_oid > > > related to tables was done at the wrong level: there should be a new > > > AlterTableNamespace_internal call that does all the extra stuff, and > > > which is to be called from AlterObjectNamespace_oid. > > > > Sounds reasonable to me. Are you going to fix it, or should I? If > > it was introduced in the extensions patch then it's my fault ... > > I'm looking into it. Here's a patch. Note I'm not attempting to create a regression test because that seems to involve setting up a fake extension which I don't know how to do (would be too messy, I think). So I tested it by having isn--1.0.sql create a table with a primary key: create the extension, alter it to move to a new schema, drop the original schema (public). If I then try to dump the database, pg_dump in current HEAD fails with "no schema with OID 2200" (not verbatim; OID is for the old public schema). It seems to me that this is exactly what was reported initially. Also I verified that psql's \d reports the inconsistency of the table and its PK. Patched code works fine. For some reason, AlterSeqNamespaces was being passed a schema name. This wasn't used and was not possible to keep in the patched code so I just removed it. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services alter-extension-schema.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7513: Cluster install failed
The following bug has been logged on the website: Bug reference: 7513 Logged by: Larry Email address: grav...@smartronix.com PostgreSQL version: 8.4.0 Operating system: win server 2003 SP2 Description: Post-Installation failed(Cluster install failed). I have gotten this error every time I have attempted to install PostgreSQL 8.4. The Data folder is created, but files are never created. therefor PostgreQL services will never start. Help -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7512: can't install pgdg-centos91-9.1-4.noarch.rpm
The following bug has been logged on the website: Bug reference: 7512 Logged by: Jana Weschenfelder Email address: s0525...@htw-berlin.de PostgreSQL version: 9.1.0 Operating system: Scientific Linux 6 Description: Hello, If I try to install Postgresql91 (in this case postgresql91-9.1.5-1PGDG.rhel6) from http://yum.pgrpms.org/9.1/redhat/rhel-6-x86_64/repoview/, I receive the message that the package "centos-release" is missing. Ok, but if I try to install "centos-release-6-3.el6.centos.9.x86_64" then, the follow error message occurs: "file /etc/issue from install of centos-release-6-3.el6.centos.9.x86_64 conflicts with file from package sl-release-6.2-1.1.x86_64" (which I understand). Does Postgresql91 really support Scientific Linux? Many thanks, Jana -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Excerpts from Tom Lane's message of vie ago 31 12:17:59 -0400 2012: > Alvaro Herrera writes: > > Aha, I see the bug. It seems the split for AlterObjectNamespace_oid > > related to tables was done at the wrong level: there should be a new > > AlterTableNamespace_internal call that does all the extra stuff, and > > which is to be called from AlterObjectNamespace_oid. > > Sounds reasonable to me. Are you going to fix it, or should I? If > it was introduced in the extensions patch then it's my fault ... I'm looking into it. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7482: lack of quotation marks in pg_env script
On Fri, Aug 31, 2012 at 5:17 PM, Bruce Momjian wrote: > On Tue, Aug 7, 2012 at 12:15:14PM +, m.skrzypkow...@o2.pl wrote: >> The following bug has been logged on the website: >> >> Bug reference: 7482 >> Logged by: Maciej Skrzypkowski >> Email address: m.skrzypkow...@o2.pl >> PostgreSQL version: 9.1.4 >> Operating system: Windows XP >> Description: >> >> In main application directory, inside pg_env.bat script there is lack of >> quotation marks for PGDATA and PGLOCALEDIR variables. > > Dave, has this been addressed? The community does not control > pg_env.bat. Not sure - the guy it was assigned to left the company yesterday to pursue an MBA. Sachin, can you check please, and fix if necessary? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Alvaro Herrera writes: > Aha, I see the bug. It seems the split for AlterObjectNamespace_oid > related to tables was done at the wrong level: there should be a new > AlterTableNamespace_internal call that does all the extra stuff, and > which is to be called from AlterObjectNamespace_oid. Sounds reasonable to me. Are you going to fix it, or should I? If it was introduced in the extensions patch then it's my fault ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7482: lack of quotation marks in pg_env script
On Tue, Aug 7, 2012 at 12:15:14PM +, m.skrzypkow...@o2.pl wrote: > The following bug has been logged on the website: > > Bug reference: 7482 > Logged by: Maciej Skrzypkowski > Email address: m.skrzypkow...@o2.pl > PostgreSQL version: 9.1.4 > Operating system: Windows XP > Description: > > In main application directory, inside pg_env.bat script there is lack of > quotation marks for PGDATA and PGLOCALEDIR variables. Dave, has this been addressed? The community does not control pg_env.bat. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6758: ./configure script sets HAVE_WCSTOMBS_L 1
On 31/08/12 15:59, Tom Lane wrote: Andrew Hastie writes: Thanks for the pointers. Hopefully some of the following may shed some light on the issue. Thanks for the results. It seems difficult to come to any conclusion other than that AIX has got wcstombs_l but not mbstowcs_l ... which is darn bizarre; I'd suggest reporting it as a bug to IBM. In the meantime, it seems like what we had better do is explicitly test for both functions, rather than making the assumption that they would both or neither be present. I'm not sure if we can provide any extra functionality if only wcstombs_l is available --- that will have to emerge in making the patch. We can certainly build without it though. As a temporary workaround, you should probably just modify pg_config.h after configure runs, to remove the HAVE_WCSTOMBS_L symbol. Confirm that the workaround works just fine. Now have PG 9.1.5 up and running on AIX just fine. Thanks. Andrew regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Excerpts from Tom Lane's message of vie jun 22 22:37:10 -0400 2012: > j...@pgexperts.com writes: > > DROP and CREATE extension appear to work fine, but if you ALTER EXTENSION > > postgis SET SCHEMA foo, it leaves a few relations behind. > > What it seems to be leaving behind is indexes ... also relation rowtypes. > > A bit of looking shows that ALTER EXTENSION SET SCHEMA calls > AlterObjectNamespace_oid on the table. AlterObjectNamespace_oid > calls AlterRelationNamespaceInternal, and nothing else. In comparison, > ALTER TABLE SET SCHEMA (AlterTableNamespace) calls > AlterRelationNamespaceInternal and about four other things. I'm not > sure if this was broken before the last round of refactoring in this > area, but for sure it's broken now. Aha, I see the bug. It seems the split for AlterObjectNamespace_oid related to tables was done at the wrong level: there should be a new AlterTableNamespace_internal call that does all the extra stuff, and which is to be called from AlterObjectNamespace_oid. FWIW this bug seems to have been introduced in the initial extensions commit, d9572c4e3b474031060189050e14ef384b94e001. Prior to that we had ExecAlterObjectSchemaStmt calling AlterTableNamespace directly. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6758: ./configure script sets HAVE_WCSTOMBS_L 1
Andrew Hastie writes: > Thanks for the pointers. Hopefully some of the following may shed some > light on the issue. Thanks for the results. It seems difficult to come to any conclusion other than that AIX has got wcstombs_l but not mbstowcs_l ... which is darn bizarre; I'd suggest reporting it as a bug to IBM. In the meantime, it seems like what we had better do is explicitly test for both functions, rather than making the assumption that they would both or neither be present. I'm not sure if we can provide any extra functionality if only wcstombs_l is available --- that will have to emerge in making the patch. We can certainly build without it though. As a temporary workaround, you should probably just modify pg_config.h after configure runs, to remove the HAVE_WCSTOMBS_L symbol. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6758: ./configure script sets HAVE_WCSTOMBS_L 1
On 29/08/12 18:16, Tom Lane wrote:
Andrew Hastie writes:
I'm currently working on a project where I need to get PGv9.1 up and
running on an IBM AIXv7.1 server, so I do have access to a suitable
machine for a period of time if I can provide any further diags to help
resolve the issue.
That would be helpful, because both of the previous complainants seem
to have wandered off without helping us get to the bottom of it :-(.
What I'd like to see at this point is the portion of config.log where
the configure script is trying to probe for wcstombs_l. For example,
on a machine that has wcstombs and not wcstombs_l, I see:
...
configure:19272: checking for wcstombs
configure:19328: gcc -o conftest -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wformat-security -fno-strict-aliasing -g -D_XOPEN_SOURCE_EXTENDEDconftest.c -lz
-lreadline -ltermcap -lm >&5
configure:19335: $? = 0
configure:19357: result: yes
configure:19272: checking for wcstombs_l
configure:19328: gcc -o conftest -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wformat-security -fno-strict-aliasing -g -D_XOPEN_SOURCE_EXTENDEDconftest.c -lz
-lreadline -ltermcap -lm >&5
/usr/ccs/bin/ld: Unsatisfied symbols:
wcstombs_l (code)
collect2: ld returned 1 exit status
configure:19335: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
| #define PACKAGE_VERSION "9.3devel"
| #define PACKAGE_STRING "PostgreSQL 9.3devel"
| #define PACKAGE_BUGREPORT "pgsql-bugs@postgresql.org"
| #define PG_VERSION "9.3devel"
| #define PG_MAJORVERSION "9.3"
| #define USE_INTEGER_DATETIMES 1
| #define DEF_PGPORT 5440
| #define DEF_PGPORT_STR "5440"
| #define BLCKSZ 8192
| #define RELSEG_SIZE 131072
| #define XLOG_BLCKSZ 8192
| #define XLOG_SEG_SIZE (16 * 1024 * 1024)
| #define USE_ASSERT_CHECKING 1
| #define PG_KRB_SRVNAM "postgres"
| #define HAVE_LIBM 1
| #define HAVE_LIBREADLINE 1
| #define HAVE_LIBZ 1
| #define HAVE_SPINLOCKS 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_CRYPT_H 1
| #define HAVE_LANGINFO_H 1
| #define HAVE_POLL_H 1
| #define HAVE_PWD_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_IPC_H 1
| #define HAVE_SYS_POLL_H 1
| #define HAVE_SYS_PSTAT_H 1
| #define HAVE_SYS_RESOURCE_H 1
| #define HAVE_SYS_SEM_H 1
| #define HAVE_SYS_SHM_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_UN_H 1
| #define HAVE_TERMIOS_H 1
| #define HAVE_UTIME_H 1
| #define HAVE_WCHAR_H 1
| #define HAVE_NET_IF_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_NETINET_TCP_H 1
| #define HAVE_READLINE_READLINE_H 1
| #define HAVE_READLINE_HISTORY_H 1
| #define WORDS_BIGENDIAN 1
| #define USE_INLINE 1
| #define HAVE_STRINGIZE 1
| #define FLEXIBLE_ARRAY_MEMBER 1
| #define HAVE_FUNCNAME__FUNC 1
| #define HAVE_TZNAME 1
| #define HAVE_UNIX_SOCKETS 1
| #define HAVE_INTPTR_T 1
| #define HAVE_UINTPTR_T 1
| #define HAVE_LONG_LONG_INT 1
| #define _FILE_OFFSET_BITS 64
| #define SIZEOF_OFF_T 8
| #define HAVE_INT_TIMEZONE /**/
| #define ACCEPT_TYPE_RETURN int
| #define ACCEPT_TYPE_ARG1 int
| #define ACCEPT_TYPE_ARG2 struct sockaddr *
| #define ACCEPT_TYPE_ARG3 size_t
| #define HAVE_CBRT 1
| #define HAVE_FDATASYNC 1
| #define HAVE_GETRLIMIT 1
| #define HAVE_MEMMOVE 1
| #define HAVE_POLL 1
| #define HAVE_PSTAT 1
| #define HAVE_READLINK 1
| #define HAVE_SETSID 1
| #define HAVE_SIGPROCMASK 1
| #define HAVE_SYMLINK 1
| #define HAVE_TOWLOWER 1
| #define HAVE_UTIME 1
| #define HAVE_UTIMES 1
| #define HAVE_WCSTOMBS 1
| /* end confdefs.h. */
| /* Define wcstombs_l to an innocuous variant, in case declares
wcstombs_l.
|For example, HP-UX 11i declares gettimeofday. */
| #define wcstombs_l innocuous_wcstombs_l
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char wcstombs_l (); below.
| Prefer to if __STDC__ is defined, since
| exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include
| #else
| # include
| #endif
|
| #undef wcstombs_l
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char wcstombs_l ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_wcstombs_l || defined __stub___wcstombs_l
| choke me
| #endif
|
| int
| main ()
| {
| return wcstombs_l ();
| ;
| return 0;
| }
configure:19357: result: no
configure:19374: checking for fseeko
...
It would also be interesting to check what would happen if configure
actua
Re: [BUGS] BUG #6489: Alter table with composite type/table
On Fri, Aug 31, 2012 at 12:32 AM, Rikard Pavelic wrote:
>
>
> I'm doing something most DBA would probably think it's a bad idea, but at
> least
> I can provide you with use case of Postgres usage.
>
There are bad ideas and there are bad ideas. The question of course is
what you get and what it costs. I think there are two big costs. The
first is that this area is full of inconsistencies in assumptions about
correct behavior and inconsistencies as you have found out. The second is
that composite types as columns make it harder for a lot of add-on
reporting tools to extract data out (which is why I think that multiple
inheritance is cleaner). But those have to be weighed against what you are
doing, naturally.
>
> We are trying to support DDD programming paradigm on top of Postgres.
> DDD modeling blocks are entities (and aggregates) and values.
> We map entities to tables and values to types.
> This fits mostly very nicely (values don't have identity, so they are
> inlined with
> other values and entities which uses them).
>
> I won't pretend to be an expert on DDD.
> What I think would be a great goal for Postgres is if lot of constraints
> would
> move from tables to types.
> This include NOT NULL, CHECK and even FOREIGN KEY (somewhere in the far
> future).
>
BTW, you can do NOT NULL and CHECK at the domain level fwiw and those will
pass through when composite types are stored.
>
> It would make me very happy if Postgres could check all constraints for
> model like this:
>
> aggregate country(code) {
> string code;
> string local_name;
> }
> aggregate person {
> string name;
> address[] addresses;
> }
> value address {
> string? street;
> string town;
> country *country; //this will create surrogate country_code field in
> address,
> //function country(address) which
> returns country
> //and it would be great if it could
> maintain relationship with country
> }
>
Take a look at recent blog entries in my blog for how to do the foreign key
dereferencing: http://ledgersmbdev.blogspot.com
Basically:
CREATE TABLE country_ref (
country_id int,
);
CREATE FUNCTION country(country_ref) RETURNS COUNTRY
STABLE LANGUAGE SQL AS $$
SELECT * FROM COUNTRY WHERE id = $1.country_id $$;
Then inherit from country and define the fkey in the child table.
>
> Currently Postgres can't declare NOT NULL for town and reference from
> address to country.
> I would be happy if direction Postgres takes would allow design like this
> to be enforced by database.
>
Sure it can:
CREATE DOMAIN not_null_string as text not null;
use not_null_string in place of text in your parent tables and it will be
enforced when pull these into the column. This is one of those
inconsistencies I mentioned above.
This is one of those reasons I don't see the backwards-compatibility
reasons so convincing. We can't create some modicum of consistency in
behavior without breaking *something.* I think the big issue is that
nobody has figured out exactly what we want to break.
Best Wishes,
Chris Travers
Re: [BUGS] BUG #6489: Alter table with composite type/table
On 29.8.2012. 21:02, Merlin Moncure wrote:
> On Wed, Aug 29, 2012 at 10:44 AM, Chris Travers
> wrote:
>
>> Again, the question is simply this:
>>
>> Are the table constraints for storage complete in themselves (and assuming
>> full knowledge of all changes of internal data types) or are they
>> encapsulated within the types?
>>
>> A nice middle ground might be domains over complex types. However, we don't
>> currently support that. Otherwise you end up with really awkward constructs
>> like:
> I don't think domains are the answer. Domains are the 'other way' --
> type default and constraints are conveyed strictly though the type.
> Superficially cool but difficult to deal with on the implementation
> side...perhaps a design error of the SQL language.
>
>> CREATE FUNCTION is_valid (mytype) RETURNS BOOL
>>
>> and then:
>>
>> check ((mytypetest).is_valid)
> You can certainly do that (as of today it's the best way). Syntax
> sugar is still sweet though. If I had a choice, I'd prefer to enforce
> constraints with CHECK vs writing a special function to do that,
> especially for trivial constraints. Either way though that's the
> behavior that should be formalized IMO.
>
>>> If you do want
>>> defaults and constraints to propagate, then I think we need new
>>> conventions to do that strictly on compatibility grounds. Maybe if
>>> you did want propagating behaviors you could explicitly ask for them:
>>
>> Given the current mess in this area, I think backwards-compatibility
>> settings on a per-database level would be sufficient.
> Disagree: compatibility .conf settings should only be introduced in
> the most dire of needs -- for example when a bad but popular behavior
> has to be taken away. So the right behavior has to bolt on, and if
> that's not possible, we are stuck with the status quo.
>
>
>> CREATE TABLE cidr_type (
>> cidr_inet_address text,
>> cidr_netmask_bits int,
>> CHECK ((cidr_inet_address IS NULL AND cidr_netmask_bits IS NULL) or
>> (cidr_inet_address IS NOT NULL AND cidr_netmask_bits IS NOT
>> NULL)
>> );
>>
>> Then I can write my functions about cidr_type and inherit it on other tables
>> and I get proper constraints, but I *cannot* use this as a column type
>> without adding functions to manage the check constraints and explicitly
>> checking them. Again if you had domains available you could create a domain
>> that would presumably be expanded in table storage.
> yes -- as noted above domains are the alternative approach -- maybe
> the better one, but I'm not sure. maybe the sql standard (which I
> don't have) might give some clues.
>
> merlin
>
I'm doing something most DBA would probably think it's a bad idea, but at least
I can provide you with use case of Postgres usage.
We are trying to support DDD programming paradigm on top of Postgres.
DDD modeling blocks are entities (and aggregates) and values.
We map entities to tables and values to types.
This fits mostly very nicely (values don't have identity, so they are inlined
with
other values and entities which uses them).
What I think would be a great goal for Postgres is if lot of constraints would
move from tables to types.
This include NOT NULL, CHECK and even FOREIGN KEY (somewhere in the far future).
It would make me very happy if Postgres could check all constraints for model
like this:
aggregate country(code) {
string code;
string local_name;
}
aggregate person {
string name;
address[] addresses;
}
value address {
string? street;
string town;
country *country; //this will create surrogate country_code field in address,
//function country(address) which returns
country
//and it would be great if it could
maintain relationship with country
}
Currently Postgres can't declare NOT NULL for town and reference from address
to country.
I would be happy if direction Postgres takes would allow design like this to be
enforced by database.
Regards,
Rikard
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
