Re: [HACKERS] [PATCHES] Avahi support for Postgresql
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Feb 23, 2008 at 01:13:38PM +0100, Mathias Hasselmann wrote: [...] Avahi/Bonjour/DNS-SD support[1] is very important, for integrating Postgresql with modern desktop environments like OSX, GNOME, KDE: It's very convenient to choose active DBMS servers in your local network from a list, instead of memorizing cryptic connection parameters. [...] People not wanting DNS-SD support for their server can easily control that feature via the --with-avahi configure scripts. Sorry for a dumb question, but I couldn't figure that out from your references [1]..[4]: does that mean that the PostgreSQL server would advertise itself on the local net? Or what is the purpose of liking-in libavahi into the postmaster? Yes, that's the purpose. Surely one wouldn't want this in a data center? Yes, this feature definitely targets small-office use, personal use, DB developers. Don't know enough about data centers to judge the impact there, but since Avahi - as used in the patch - announces to the local network only, the impact sould be small. Still you can tell Avahi to explicitly announce at a certain, non-local domain, but this feature is not implemented by the patch. Maybe database developers in large network environments could make use of such announcements. It would be trivial to add. Is there a possiblity to disable that at run time? The feature is disabled by default. As long as you do not specify a zeroconf_name in your configuration file, nothing happens. This is the same behavior as established by the Bonjour code. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://www.openismus.com/ - We can get it done. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Avahi support for Postgresql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote: Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]: [...] Sorry for a dumb question, but I couldn't figure that out from your references [1]..[4]: does that mean that the PostgreSQL server would advertise itself on the local net? Or what is the purpose of liking-in libavahi into the postmaster? Yes, that's the purpose. Surely one wouldn't want this in a data center? Yes, this feature definitely targets small-office use, personal use, DB developers [...] Still you can tell Avahi to explicitly announce at a certain, non-local domain, but this feature is not implemented by the patch. Maybe database developers in large network environments could make use of such announcements. It would be trivial to add. Personally, I'be rather scared than delighted ;-) Is there a possiblity to disable that at run time? The feature is disabled by default. As long as you do not specify a zeroconf_name in your configuration file, nothing happens. This is the same behavior as established by the Bonjour code. Thanks, good to know. Isn't there a less-intrusive option to linking a lib into each and every possible server, like a config file in which to put what is to be announced? Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH8iRFBcgs9XrR2kYRAmJ0AJkB7MkxfYI0nVa4RqHVEV1HYjz41gCdEgWz YQ2T4Y/xfoLRF4D6hMLbpEk= =Goho -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Improve shutdown during online backup
This follows up on the discussion in http://archives.postgresql.org/pgsql-hackers/2008-03/msg01033.php - pg_ctl will refuse a smart shutdown during online backup. - The postmaster will also refuse to shutdown in smart mode in that case and log a message to that effect. - In fast shutdown mode, the server will rename backup_label after successfully shutting down and log the fact. Yours, Laurenz Albe backup-shut.doc.patch Description: backup-shut.doc.patch backup-shut.patch Description: backup-shut.patch -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] psql command aliases support
Folks,
please find attached a patch which implements psql command aliases. They
work the same way as on bash, zsh and others, for example:
#= \alias d \dt+
#= \d
List of relations
Schema | Name | Type | Owner | Description
+--+---+---+-
public | foo | table | bernd |
(1 row)
=# \alias current_query SELECT current_query, NOW() - query_start FROM
pg_stat_activity WHERE current_query NOT LIKE 'IDLE%';
#= \current_query
current_query
| ?column?
---+--
SELECT current_query, NOW() - query_start FROM pg_stat_activity WHERE
current_query NOT LIKE 'IDLE%'; | 00:00:00
(1 row)
#= \unalias d
#= \d
List of relations
Schema | Name | Type | Owner
+--+---+---
public | foo | table | bernd
(1 row)
I hope i broke nothing and maybe we find this useful for 8.4, documentation
included.
--
Thanks
BerndIndex: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.199
diff -c -B -r1.199 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml 30 Mar 2008 18:10:20 - 1.199
--- doc/src/sgml/ref/psql-ref.sgml 1 Apr 2008 14:05:05 -
***
*** 685,690
--- 685,708
/varlistentry
varlistentry
+ termliteral\alias replaceable class=parameteraliasname/replaceable replaceable class=parameteraliascommand/replaceable/literal/term
+ listitem
+ para
+ The literal\alias/literal backslash command allows defining your own backslash commands or an alias for an existing built-in command. The alias is allowed to call a SQL command or any other backslash command or aliases already defined. For example:
+ programlisting
+ =gt; userinput\alias watch_idle_tx SELECT xact_start, datid, datname, procpid, usesysid FROM pg_stat_activity WHERE current_query LIKE '%IDLE%';/userinput
+ =gt; userinput\watch_idle_tx/userinput
+ xact_start | datid | datname | procpid | usesysid
+ ---+---+-+-+--
+ 2008-03-07 14:59:25.618827+01 | 24576 | db | 28864 | 10
+ (1 row)
+ /programlisting
+ Calling command\alias/command without an replaceable class=parameteraliasname/replaceable just shows a list of all defined aliases, with an existing replaceable class=parameteraliasname/replaceable its assigned replaceable class=parameteraliascommand/replaceable is shown. You can use the command\unalias/command to remove an alias.
+ /para
+ /listitem
+ /varlistentry
+
+ varlistentry
termliteral\cd [ replaceabledirectory/replaceable ]/literal/term
listitem
para
***
*** 1849,1854
--- 1867,1880
/listitem
/varlistentry
+ varlistentry
+ termliteral\unalias replaceable class=parameteraliascmd/replaceable/literal/term
+ listitem
+ para
+ Removes the specified alias from the list.
+ /para
+ /listitem
+ /varlistentry
varlistentry
termliteral\w/literal {replaceable class=parameterfilename/replaceable | replaceable class=parameter|command/replaceable}/term
Index: src/bin/psql/command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.186
diff -c -B -r1.186 command.c
*** src/bin/psql/command.c 1 Jan 2008 19:45:55 - 1.186
--- src/bin/psql/command.c 1 Apr 2008 14:05:06 -
***
*** 199,204
--- 199,251
backslashResult status = PSQL_CMD_SKIP_LINE;
/*
+ * We want to look for aliases first, since we want them to override a
+ * built-in command, so our users are able to define their own behavior
+ * on their favourite backslash command.
+ */
+ const char *aliascmd = GetVariable(pset.aliases, cmd);
+
+ if (aliascmd)
+ {
+ /* Save the current alias substitution string.
+ * We do this to prevent infinite recursion into the aliases
+ * list.
+ */
+ const char *substalias = GetVariable(pset.substaliases, cmd);
+
+ if (substalias != NULL)
+ {
+ /* already substituted, nothing more to do */
+ DeleteVariable(pset.substaliases, cmd);
+ }
+ else
+ {
+ char *opt;
+ SetVariable(pset.substaliases, cmd, 1);
+
+ /* save the substituted command to the query buffer but save
+ * additional parameter lists also
+ */
+ resetPQExpBuffer(query_buf);
+ appendPQExpBuffer(query_buf, aliascmd);
+
+ if ((opt = psql_scan_slash_option(scan_state,
+ OT_WHOLE_LINE, NULL, false)))
+ {
+ appendPQExpBuffer(query_buf, );
+ appendPQExpBuffer(query_buf, opt);
+ }
+
+ success =
Re: [HACKERS] [PATCHES] Avahi support for Postgresql
Am Dienstag, den 01.04.2008, 12:02 + schrieb [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote: Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]: [...] Sorry for a dumb question, but I couldn't figure that out from your references [1]..[4]: does that mean that the PostgreSQL server would advertise itself on the local net? Or what is the purpose of liking-in libavahi into the postmaster? Yes, that's the purpose. Surely one wouldn't want this in a data center? Yes, this feature definitely targets small-office use, personal use, DB developers [...] Still you can tell Avahi to explicitly announce at a certain, non-local domain, but this feature is not implemented by the patch. Maybe database developers in large network environments could make use of such announcements. It would be trivial to add. Personally, I'be rather scared than delighted ;-) So in data centers you don't even trust the machines in your broadcast domain? Is there a possiblity to disable that at run time? The feature is disabled by default. As long as you do not specify a zeroconf_name in your configuration file, nothing happens. This is the same behavior as established by the Bonjour code. Thanks, good to know. Isn't there a less-intrusive option to linking a lib into each and every possible server, like a config file in which to put what is to be announced? You could directly talk to the D-Bus interface of Avahi. libavahi-client just is a convenience wrapper. Well, but this route will be much more cumbersome. One other route is calling avahi-publish-service on startup and killing it on shutdown, but: avahi-publish-service really only exists for demonstration purposes and doesn't handle service name collisions for instance. I don't believe that a high-profile application like Postgresql should rely on low-quality hacks, like invoking educational demo programs. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://www.openismus.com/ - We can get it done. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Avahi support for Postgresql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 01, 2008 at 05:07:31PM +0200, Mathias Hasselmann wrote: [...] Personally, I'be rather scared than delighted ;-) So in data centers you don't even trust the machines in your broadcast domain? Kind of. Put it another way: never have services running you don't use. [...] Isn't there a less-intrusive option to linking a lib into each and every possible server, like a config file in which to put what is to be announced? You could directly talk to the D-Bus interface of Avahi. libavahi-client just is a convenience wrapper. Well, but this route will be much more cumbersome. So this goes through the D-Bus. Makes kind of sense. Thanks for the enlightenment. One other route is calling avahi-publish-service on startup and killing it on shutdown, but: avahi-publish-service really only exists for demonstration purposes and doesn't handle service name collisions for instance. I don't believe that a high-profile application like Postgresql should rely on low-quality hacks, like invoking educational demo programs. Unelegant as it might seem -- this solution still affords a lot more when it comes to separation of concerns. I'm still a bit wary at the prospect that each and every daemon evolves into a huge fuzzball linked to all conceivable service-lets with a multitude of funny side-effects (remember tcpwrappers?). Of course, you can always disable this at compile time, but let's face it: with the predominance of binary distribs, the path of least resistance will be to put up with whatever strange side-effects. I would really prefer a more loosely coupled system. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH8lYJBcgs9XrR2kYRAmDJAJ4jWKYkhUfKEAIaZVnIbAAEqJF2AwCfS/6D 4rH9OoY7wjia7h1cuk5CjZI= =AF1W -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] psql command aliases support
Bernd Helmle [EMAIL PROTECTED] writes: please find attached a patch which implements psql command aliases. They work the same way as on bash, zsh and others, for example: #= \alias d \dt+ #= \d Do we really want such a thing? The space of backslash command names is so densely populated already that it's hard to imagine creating aliases without conflicting with existing (or future) command names --- as indeed your example does. It seems like mostly a recipe for confusion. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] psql command aliases support
Am Dienstag, 1. April 2008 schrieb Tom Lane: Do we really want such a thing? Yes! The space of backslash command names is so densely populated already that it's hard to imagine creating aliases without conflicting with existing (or future) command names --- as indeed your example does. It seems like mostly a recipe for confusion. This is a standard feature and effect on shells. Shells have even more likely commands and conflicts, and still aliases are widely used. If people are concerned about conflicts, they shouldn't use aliases. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] psql command aliases support
--On Dienstag, April 01, 2008 11:39:59 -0400 Tom Lane [EMAIL PROTECTED] wrote: Do we really want such a thing? Well, i use aliases everytime and everywhere they got implemented and i found it quite useful to _extend_ existing behavior (integrating additional functionality in an easy way) The space of backslash command names is so densely populated already that it's hard to imagine creating aliases without conflicting with existing (or future) command names I often found existing backslash command sometimes overloaded or simply not providing information i really need (for example, an easy way to get information about current locales, encoding and user settings). You simply can't catch all requirements DBA's and users want within a all-catching implementation. Using this way, users are able to implement their own command shortcuts Overriding existing backslash commands (as my first example shows) is only an implementation-specific detail which could easily forbidden. However, defining your own shortcuts for your psql-sessions looks quite useful to me, like my 2nd example tries to illustrate. It seems like mostly a recipe for confusion. So what? This could happen in every shell that supports aliases as well. I don't get your point...? -- Thanks Bernd -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Minor changes to Recovery related code
On Thu, 2008-03-27 at 17:34 +, Simon Riggs wrote: Follow-up during March 2008 CommitFest On Thu, 2007-06-07 at 21:53 +0100, Simon Riggs wrote: On Sat, 2007-03-31 at 00:51 +0200, Florian G. Pflug wrote: - pg_stop_backup() will wait until the WAL file that ends the backup is safely archived, even if a failure to archive occurs. This is a change to current behaviour, but since it implements the originally *expected* behaviour IMHO it should be the default. The most straightforward thing is to make pg_stop_backup() wait as described above. If people want it to timeout, they can use a statement_timeout as suggested by Florian. This can be implemented by having the function poll in an infinite loop for archive_status/LOG.done. Also, as Florian suggests, we should have it output a WARNING message every 60 seconds. I'll write a patch now. Patch to implement waiting pg_stop_backup(). Tested and ready to apply, includes docs. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk Index: doc/src/sgml/backup.sgml === RCS file: /home/sriggs/pg/REPOSITORY/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.116 diff -c -r2.116 backup.sgml *** doc/src/sgml/backup.sgml 28 Mar 2008 15:00:28 - 2.116 --- doc/src/sgml/backup.sgml 31 Mar 2008 14:11:59 - *** *** 761,772 para Once the WAL segment files used during the backup are archived, you are done. The file identified by functionpg_stop_backup/'s result is ! the last segment that needs to be archived to complete the backup. Archival of these files will happen automatically, since you have already configured varnamearchive_command/. In many cases, this happens fairly quickly, but you are advised to monitor your archival ! system to ensure this has taken place so that you can be certain you ! have a complete backup. /para /listitem /orderedlist --- 761,779 para Once the WAL segment files used during the backup are archived, you are done. The file identified by functionpg_stop_backup/'s result is ! the last segment that is required to form a complete set of backup files. ! functionpg_stop_backup/ does not return until the last segment has ! been archived. Archival of these files will happen automatically, since you have already configured varnamearchive_command/. In many cases, this happens fairly quickly, but you are advised to monitor your archival ! system to ensure there is no delay. ! If the archival process has fallen significantly behind ! because of failures of the archive command then we will keep waiting ! and retrying until the archive succeeds and the backup is complete. ! If you wish to place a time limit on the execution of ! functionpg_stop_backup/ then you should set an appropriate ! varnamestatement_timeout/varname. /para /listitem /orderedlist *** *** 1044,1050 note para The stop point must be after the ending time of the base backup, i.e., ! the time of functionpg_stop_backup/. You cannot use a base backup to recover to a time when that backup was still going on. (To recover to such a time, you must go back to your previous base backup and roll forward from there.) --- 1051,1057 note para The stop point must be after the ending time of the base backup, i.e., ! the end time of functionpg_stop_backup/. You cannot use a base backup to recover to a time when that backup was still going on. (To recover to such a time, you must go back to your previous base backup and roll forward from there.) *** *** 1322,1327 --- 1329,1335 After the backup the switch file is removed. Archived WAL files are then added to the backup so that both base backup and all required WAL files are part of the same applicationtar/ file. + Please remember to add error handling to your backup scripts. /para /sect3 Index: src/backend/access/transam/xlog.c === RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/transam/xlog.c,v retrieving revision 1.295 diff -c -r1.295 xlog.c *** src/backend/access/transam/xlog.c 25 Mar 2008 22:42:42 - 1.295 --- src/backend/access/transam/xlog.c 1 Apr 2008 16:08:07 - *** *** 382,388 static void XLogArchiveNotify(const char *xlog); static void XLogArchiveNotifySeg(uint32 log, uint32 seg); ! static bool XLogArchiveCheckDone(const char *xlog); static void XLogArchiveCleanup(const char *xlog); static void readRecoveryCommandFile(void); static void exitArchiveRecovery(TimeLineID endTLI,
Re: [PATCHES] Improve shutdown during online backup
On Tue, 2008-04-01 at 15:34 +0200, Albe Laurenz wrote: This follows up on the discussion in http://archives.postgresql.org/pgsql-hackers/2008-03/msg01033.php - pg_ctl will refuse a smart shutdown during online backup. - The postmaster will also refuse to shutdown in smart mode in that case and log a message to that effect. - In fast shutdown mode, the server will rename backup_label after successfully shutting down and log the fact. Looks good. Few comments: * smart shutdown waits for sessions to complete, yet this just ignores smart shutdowns which is something a little different. I think we should wait for the backup to complete and then shutdown. * when we say online backup cancelled I think we should say something more like online backup mode cancelled. All we are doing is removing the backup label file, we're not actually cancelling the physical backup since it is external to the database anyway. * The #defines at top of postmaster.c are duplicated from xlog.c If we can't agree on a common header file then we should at least add a comment to mention they are duplicated (in both locations). -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Improve shutdown during online backup
On Tue, 2008-04-01 at 17:42 +0100, Simon Riggs wrote:
Few comments:
* smart shutdown waits for sessions to complete, yet this just ignores
smart shutdowns which is something a little different. I think we
should wait for the backup to complete and then shutdown.
* The #defines at top of postmaster.c are duplicated from xlog.c
If we can't agree on a common header file then we should at least add a
comment to mention they are duplicated (in both locations).
If we add a function called something like BackupInProgress() to xlog.c,
exported via miscadmin.h then we can use it within the
PostmasterStateMachine() function like this
if (pmState == PM_WAIT_BACKENDS)
{
if (CountChildren() == 0
StartupPID == 0
(BgWriterPID == 0 || !FatalError)
WalWriterPID == 0
AutoVacPID == 0
!BackupInProgress()) new line
so that the postmaster doesn't need to know about how we do backups.
That way you don't need any of the special cases in your patch, nor is
there any need to duplicate the #defines.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
On Tue, Apr 01, 2008 at 12:58:44AM -0400, Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: One --perhaps nice, perhaps not-- property of this is that if you defined a function named rtrim and then did \df rtrim it would show you _both_ the system and user function and make it easier to see the conflict. Whereas the other behaviour I proposed would hide the system function which might exacerbate the user's confusion. Another way we could approach this is ... That doesn't satisfy the original source of the annoyance which is that \df spams your terminal with ten screens of system functions with your user functions hidden amongst them. Sure, but I think the core objection there is that there is no easy way to see only the user-defined functions. Given your point quoted first above, I'm unconvinced that should be the default behavior. When we have a bad default--and I'd argue that for anyone not developing PostgreSQL itself, showing system functions is a bad default--we should change it to something sane. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
David Fetter [EMAIL PROTECTED] writes: When we have a bad default--and I'd argue that for anyone not developing PostgreSQL itself, showing system functions is a bad default--we should change it to something sane. I disagree with your parenthetical argument here, mainly on the strength of Greg's point about how that might hide the existence of conflicts. But in any case the discussion here is first about what set of behaviors we need to provide, and only second about which one should be default. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2008, Tom Lane wrote: David Fetter writes: When we have a bad default--and I'd argue that for anyone not developing PostgreSQL itself, showing system functions is a bad default--we should change it to something sane. I disagree with your parenthetical argument here, mainly on the strength of Greg's point about how that might hide the existence of conflicts. But in any case the discussion here is first about what set of behaviors we need to provide, and only second about which one should be default. If I read Greg's latter proposal correctly, he was suggesting \df Lists all user functions \df [pattern] Lists both system and user functions matching [pattern] \df * Lists all system and user functions This doesn't provide is all system functions only, but: 1. That list is way too long to be of much use in a psql context 2. You can still do a \df pg_catalog.* if you're really that keen. It also doesn't provide only user functions matching [pattern], but is that really a problem? I suppose you could conceive of a situation where somebody is looking for all the user funcs matching int* and getting annoyed by having to scroll past ~200 system funcs, but you can always refine your pattern, or clamp it to a particular schema. Regards, BJ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFH8qtm5YBsbHkuyV0RAkXlAKCH8lL9H8XInLRvlbKnh84XafXyZwCg2Qom a3TuUMKHH7Yq/zZaA4MI7hk= =yLQJ -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
Pavel Stehule [EMAIL PROTECTED] writes: I actualized sql/psm patch. This patch can be downloaded from http://www.pgsql.cz/patches/plpgpsm.diff.gz The fundamental problem I've got with this patch is that it adds 400K of new code (and that's just the code, not counting documentation or regression tests) that we'll have to maintain, to obtain a feature that so far as I've heard there is precisely zero demand for. The duplicativeness of the code with plpgsql doesn't make this prospect any more pleasant, either. The idea would be a lot easier to swallow if the code were refactored to avoid the duplication with plpgsql. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Avahi support for Postgresql
On Tue, 2008-04-01 at 15:34 +, [EMAIL PROTECTED] wrote: I would really prefer a more loosely coupled system. The functionality will be much the same. The implementation would be more difficult and obscure and there would be more points of failure and more things to configure, but it wouldn't remove much risk, I think. Anyway, this feature is already in Postgres when it's built for MacOS X. So this decision seems to have been made already, at least for that platform. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
Brendan Jurd [EMAIL PROTECTED] writes: If I read Greg's latter proposal correctly, he was suggesting \df Lists all user functions \df [pattern] Lists both system and user functions matching [pattern] \df * Lists all system and user functions Hmm, I must've misread it, because I didn't understand it quite like that. That seems like a nice simple minimal-featuritis approach. One question: should \df really list *all* nonsystem functions? Or just the ones that are visible in your search path? I'd be inclined to say the second. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
Tom Lane wrote: One question: should \df really list *all* nonsystem functions? Or just the ones that are visible in your search path? I'd be inclined to say the second. +1 (although maybe that discussion belongs on -hackers, or even -general) cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Consistent \d commands in psql
Tom Lane [EMAIL PROTECTED] writes: Brendan Jurd [EMAIL PROTECTED] writes: If I read Greg's latter proposal correctly, he was suggesting \df Lists all user functions \df [pattern] Lists both system and user functions matching [pattern] \df * Lists all system and user functions Hmm, I must've misread it, because I didn't understand it quite like that. That seems like a nice simple minimal-featuritis approach. Sorry if was confusing but yes, that is what I intended by my second proposal. I prefer it to my own first proposal or any of the others. I admit I was thinking primarily of non-globbing cases for pattern. As in, I would want \df rtrim to work. I suppose it could be annoying to have to type \df public.* -- there's nothing stopping us from having \dfU and \dfS too I suppose, though I doubt most people would find them. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] script binaries renaming
FYI, the patch author and survey requestor has withdrawn the patch with the following comment: I think we can reject this patch. I don't process yet output from survey on general, but it seems that more users prefer pg_ prefix, but idea of pgc command seems to be better. I think it is good idea for 9.0 release. The TODO item has been removed as well: * Prefix command-line utilities like createuser with 'pg_' http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php --- Zdenek Kotala wrote: Tom Lane napsal(a): Bruce Momjian [EMAIL PROTECTED] writes: Where are we on this? Tom thinks we don't want this. TODO has: * Prefix command-line utilities like createuser with 'pg_' http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php I think we need to make a decision. Well, I don't have any particular objection to adding pg_ prefixes as alternate names for the existing scripts. However, it's not clear what is the point unless we have the intention to remove the old names at some time in the foreseeable future. And the consensus of the previous thread on -patches seemed to be that nobody except Zdenek was very eager to do that. Yeah, I have to had two reason for this patch. First is my personal, because I don't like these names since 1999. And second is that Solaris architects do not like these names. Especially createdb and createuser. It could clash with some system utility. In any case, there is no value in discussing this further on -patches since the readers of this list already weighed in. If you want to make a decision then it needs to be made on -hackers or -general. I think both are important (maybe general is more important). Maybe we can put also a survey on webpage. On other side. The question is also if we really still need these utilities? If you look on them there are missing features. E.g vacuumdb does not allow make VACUUM FREEZ or set some modern version of vacuum parameters. There is not createtablespace command and so on... Zdenek -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] actualized SQL/PSM patch
Hello On 01/04/2008, Tom Lane [EMAIL PROTECTED] wrote: Pavel Stehule [EMAIL PROTECTED] writes: I actualized sql/psm patch. This patch can be downloaded from http://www.pgsql.cz/patches/plpgpsm.diff.gz The fundamental problem I've got with this patch is that it adds 400K of new code (and that's just the code, not counting documentation or regression tests) that we'll have to maintain, to obtain a feature that so far as I've heard there is precisely zero demand for. The duplicativeness of the code with plpgsql doesn't make this prospect any more pleasant, either. The idea would be a lot easier to swallow if the code were refactored to avoid the duplication with plpgsql. This is long run and needs hard reorganisation of plpgsql code. And moving some plpgsql code to core. But I don't expect so plpgpsm code can be less than 200KB. Regards Pavel Stehule regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
