Re: [HACKERS] Declarative partitioning - another take
El 2016-10-28 07:53, Amit Langote escribió:
@@ -6267,6 +6416,12 @@ ATAddForeignKeyConstraint(AlteredTableInfo *tab,
Relation rel,
* Validity checks (permission checks wait till we have the column
* numbers)
*/
+ if (pkrel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("cannot reference relation \"%s\"",
RelationGetRelationName(pkrel)),
+ errdetail("Referencing partitioned tables in foreign key
constraints is not supported.")));
Is there a plan for fixing this particular limitation? It's a pretty
serious problem for users,
and the suggested workaround (to create a separate non-partitioned table
which carries only the PK
columns which is updated by triggers, and direct the FKs to it instead
of to the partitioned table)
is not only a very ugly one, but also very slow.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to pass around collation information
Excerpts from Peter Eisentraut's message of vie may 28 12:27:52 -0400 2010: > Option 2, invent some new mechanism that accompanies a datum or a type > whereever it goes. Kind of like typmod, but not really. Then the > collation information would presumably be made available to functions > through the fmgr interface. The binary representation of data values > stays the same. Is the collation a property of the datum, or one of the comparison? If the latter, should it be really be made a sidecar of a datum, or would it make more sense to attach it to the operation being performed? I wonder if instead of trying to pass it down multiple layers till bttextcmp and further down, it would make more sense to set a global variable somewhere in the high levels, and only have it checked in varstr_cmp. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] List traffic
Excerpts from Josh Berkus's message of jue may 27 14:11:51 -0400 2010: > Only someone who is a postgresql developer would consider 15-30 > posts/day "small". For most of our user base, the level of traffic on > -performance, -sql, and -general is already too high and many people > don't subscribe to these lists because it is too high. I get complaints > -- and people personal-sending me questions because they don't want to > subscribe -- all the time. People can post without being subscribed, and most people around here will CC them when they reply. That's supposed to be a feature of our lists. Maybe when you receive such a question you can forward it to a list CCing the person. Not that I disagree with your opinion that a smaller list is desirable. I think collapsing lists into -general or whatever would be a terrible idea. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [ADMIN] command tag logging
Excerpts from Tom Lane's message of jue may 27 12:49:49 -0400 2010: > alvherre writes: > > Excerpts from Ray Stell's message of mié may 26 17:08:33 -0400 2010: > >> I just installed a compiled from src 8.3.11. I usually include %i, > >> command tag, > >> in the log_line_prefix setting. This causes some spewage I'd not seen > >> before > >> on connection received lines as if it is dumping the environment: > > > Hmm, I bet it's the recent %.*s patch. > > That is in the right place, isn't it. That would suggest that > get_ps_display() is returning a wrong length on Ray's machine. > It works okay here, but since that's platform-specific code that > hardly proves much. Ray, what platform is this exactly? FWIW it fails for me too (Debian running Linux 2.6.32). Adding some logging to stderr results in this: psdisp (len 2130) is: “““/pgsql/install/83_rel/bin/postmaster””” /pgsql/install/83_rel/bin/postmasterPGDATA=/pgsql/install/83_rel/dataORBIT_SOCKETDIR=/home/alvherre/tmp/orbit-alvherreSSH_AGENT_PID=2739GPG_AGENT_INFO=/tmp/gpg-aXAHSs/S.gpg-agent:2704:1SHELL=/bin/bashTERM=xtermXDG_SESSION_COOKIE=e50959452240490c59b0366b96665400-1274967349.87074-853952583HISTSIZE=1TMPDIR=/home/alvherre/tmpGTK_RC_FILES=/etc/gtk/gtkrc:/home/alvherre/.gtkrc-1.2-gnome2WINDOWID=29360152GNOME_KEYRING_CONTROL=/home/alvherre/tmp/keyring-EUoSfgGTK_MODULES=canberra-gtk-moduleUSER=alvherrehttp_proxy=http://localhost:8118XTERM_SHELL=/bin/bashHISTFILESIZE=1LD_LIBRARY_PATH=/pgsql/install/83_rel/libLS_COLORS=no=00:fi=00:di=01;35:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.tar=01;31:*.tgz=01;31:*.tbz2=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lha=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.jpg=01 ;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:*.tiff=01;35:SSH_AUTH_SOCK=/home/alvherre/tmp/keyring-EUoSfg/sshTMOUT=0USERNAME=alvherreSESSION_MANAGER=local/perhan:@/tmp/.ICE-unix/2689,unix/perhan:/tmp/.ICE-unix/2689PAGER=lessDESKTOP_SESSION=gnomePATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/alvherre/bin:/sbin:/usr/sbinGDM_XSERVER_LOCATION=localPX_CONFIG_ORDER=envvarPWD=/home/alvherreEDITOR=vimLANG=es_CL.UTF-8GDM_LANG=es_CL.UTF-8TZ=America/SantiagoGDMSESSION=gnomeHISTIGNORE=ls:bg:fg:cd:exit:XTERM_VERSION=XTerm(256)XTERM_LOCALE=es_CL.UTF-8HISTCONTROL=ignorespace:erasedupsHOME=/home/alvherreSHLVL=1GNOME_DESKTOP_SESSION_ID=this-is-deprecatedno_proxy=localhost,127.0.0.0/8BASH_ENV=/home/alvherre/.bashrcLOGNAME=alvherreLESS=-XRM -x4VISUAL=vimXDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/:/usr/share/gdm/DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-TnbbC5PUiR,guid=833f76565b26a89543f6aa42004f_PX_CONFIG _ORDER=WINDOWPATH=7DISPLAY=:0.0HOSTFILE=/home/alvherre/.hostsXAUTHORITY=/home/alvherre/.Xauthority LOG: connection received: host=[local] Maybe the problem is the PS_PADDING setting? I patched as below -- obviously the \0 didn't make any difference (it was the first thing I tried), because the length, as you say, is wrong. *** log_line_prefix(StringInfo buf) *** 1615,1621 --- 1615,1623 int displen; psdisp = get_ps_display(&displen); + fprintf(stderr, "psdisp (len %d) is: “““%s”””\n", displen, psdisp); appendBinaryStringInfo(buf, psdisp, displen); + appendStringInfoChar(buf, '\0'); } break; case 'r': -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] functional call named notation clashes with SQL feature
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010: > I think we should fix it now. Quick thought: maybe we could use FOR > instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's > mechanism for this is 'paramname => value', but I think that has > problems because of our possibly use of => as an operator - otherwise > that would be by far the best way to go. I think we were refraining from => because the standard didn't specify this back then -- AFAIU this was introduced very recently. But now that it does, and that the syntax we're implementing conflicts with a different feature, it seems wise to use the standard-mandated syntax. The problem with the => operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Perhaps we could allow "=>" to resolve as the operator for the case the user really needs to use it; or a schema-qualified operator. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [ADMIN] command tag logging
Excerpts from Ray Stell's message of mié may 26 17:08:33 -0400 2010: > I just installed a compiled from src 8.3.11. I usually include %i, command > tag, > in the log_line_prefix setting. This causes some spewage I'd not seen before > on connection received lines as if it is dumping the environment: > > [unknown],17462,[unknown],2010-05-26 16:04:33.293 > EDT,4bfd7ed1.4436,1,2010-05-26 16:04:33 > EDT,0,/usr/local/pgsql8311/bin/postgres-D/var/database/pgsql/alerts_subscribeMANPATH=/usr/local/pgsql/man:HOSTNAME=test.cns.vt.eduTERM=xtermSHELL=/bin/bashHISTSIZE=1000ANT_HOME=/var/local/apache-antUSER=postgresqlLS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:LD_LIBRARY_PATH=/usr/lib/openssl/:/usr/local/pgsql/lib:PATH=/usr/java/jdk1.6.0_20/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/db03/app/oracle/product/11.1.0/bin:/var/local/apache-ant/bin:/usr/local/maven/bin:/usr/local/pgsql/bi nMAIL=/var/spool/mail/postgresql_=/usr/local/pgsql8311/bin/postgresPWD=/home/postgresqlINPUTRC=/etc/inputrcJAVA_HOME=/usr/java/jdk1.6.0_20LANG=en_US.UTF-8PGSYSCONFDIR=/usr/local/pgsql8311/etcSSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpassPGDIR=/usr/local/pgsqlHOME=/home/postgresqlSHLVL=2M2_HOME=/usr/local/mavenLOGNAME=postgresqlCVS_RSH=/usr/bin/sshPGDATA=/var/database/pgsql/alerts_subscribeLESSOPEN=|/usr/bin/lesspipe.sh %sORACLE_HOME=/db03/app/oracle/product/11.1.0G_BROKEN_FILENAMES=1 LOG: connection received: host=198.82.3.23 port=49723 Hmm, I bet it's the recent %.*s patch. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Show schema name on REINDEX DATABASE
Excerpts from Selena Deckelmann's message of mié may 26 11:07:40 -0400 2010: > On Mon, Apr 5, 2010 at 9:29 AM, Greg Sabino Mullane wrote: > > Patch attached to show the schema *and* table name when doing > > a REINDEX DATABASE. > > Is this something that can be added to 9.1 commitfest? Not in this form, apparently. Can we convince Greg or someone else to work on adding some more error message fields? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Regression testing for psql
Excerpts from Stephen Frost's message of mié may 26 15:19:59 -0400 2010: > * Robert Haas (robertmh...@gmail.com) wrote: > > Then, too, there's the fact that many of these tests fail on my > > machine because my username is not sfrost, > > I've updated the patch to address this, it's again at: > http://snowman.net/~sfrost/psql-regress-help.patch Isn't this kind of test a pain to maintain? If somebody add a new SQL command, it will affect the entire \h output and she'll have to either apply the changes without checking them, or manually check the complete list. I have only to add a new function to make the test fail ... Also, having to exclude tests that mention the database owner means that you're only testing a fraction of the commands, so any possible problem has a large chance of going undetected. I mean, if we're going to test this kind of thing, shouldn't we be using something that allows us to ignore the db owner name? A simple wildcard in place of the owner name would suffice ... or do we need a regex for some other reason? The \h output normally depends on terminal width. Have you handled that somehow? (And if we want something like this, I think we should not have a single huge file for the complete test, but a set of smaller files. I'd even put the bunch in src/bin/psql/regress rather than the main regress dir.) -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mapping object names to role IDs
Excerpts from Robert Haas's message of mié may 26 10:34:00 -0400 2010: > lsyscache.c might have no conceptual consistency but it's extremely > useful, I know I've been annoyed by lsyscache: looking for accessors to catalog stuff, not finding them and so creating my own by using syscache directly, only to find out later that they already existed there. I think we should be moving in the direction of *removing* lsyscache, not replicating it. BTW I quite agree with both the suggestion you give in this thread (modulo this issue), and Peter's idea of getting rid of the repetitive syscache coding pattern. > and there are > plenty of other examples of where we've put code for different object > types into a single file to simplify maintenance and reduce code > complexity (e.g. copyfuncs, equalfuncs, outfuncs, etc.). Well, that's all related to node manipulation, so I'm not so sure it's exactly the same. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mapping object names to role IDs
Excerpts from Robert Haas's message of mié may 26 07:20:30 -0400 2010: > I still feel that we'd be better off putting all the functions that > use the same design pattern in a single file, rather than spreading > them out all over the backend. It's true that that one file will then > depend on all the catalog stuff, but it actually can limit > dependencies a little bit on the other end, because if someone wants > to call a bunch of these functions from the same file, they only need > to include the one header where they are all declared, rather than all > the individual files that contain the individual functions. This doesn't buy you anything, because that one header will likely have to #include all the other headers anyway. And if this is so, then all those headers will now be included in all files that require even a single one of these functions. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Approved
Please see the attached file for details. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
