Re: [HACKERS] perl namespace for postgres specific modules?
Andrew Hammond wrote: > I need to write a perl module which will parse a .pgpass file into a > reasonable data-structure in memory. I may extend it later to go in the > other direction (given a populated datastructure, write a .pgpass). > > The first question that came to mind is what namespace should I put > this under? Is there any precedent for perl modules intended to support > postgresql administration? If not, I suggest > > PostgreSQL::pgpass > IIRC it is conventional to begin each section of a perl namespace with an upper case char. That's what I tend to do at any rate. (Of course, namespaces aren't really hierarchical, but it's a nice illusion.) Other than that it seems reasonable. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] New variable server_version_num
On Sat, Jul 29, 2006 at 09:14:16PM -0400, Greg Sabino Mullane wrote: > Today on IRC David Fetter and some others were discussing version > numbers and we realized that although libpq now provides the version > of Postgres as a number, this is still a wheel that is being > reinvented by apps many times over, as it is not available any other > way. Hence, a small patch to provide a new variable > "server_version_num", which is almost the same as "server_version" > but uses the handy PG_VERSION_NUM which allows apps to do things > like if ($version >= 80200) without having to parse apart the value > of server_version themselves. What's the status on applying this patch? Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] Forcing current WAL file to be archived
On Aug 10, 2006, at 7:57 AM, Tom Lane wrote: Anyway, after further thought I've concluded that we really should supply something that returns the Insert pointer, as this would be useful for debugging and system-monitoring purposes. It's clear however that we also need something that returns the Write pointer, as that's what's needed for partial log-shipping. So my vote is for two functions, both read-only (and hence not superuser-only). Not sure what to name them exactly. Dumb question... is there any need to be able to get those values in sync (I'm assuming that in the time taken to call two separate functions the value on the second function called could change from what it was when the first function was called)? Should there be a SRF that returns both values? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] perl namespace for postgres specific modules?
11 Aug 2006 15:57:42 -0700, Andrew Hammond <[EMAIL PROTECTED]>: I need to write a perl module which will parse a .pgpass file into a reasonable data-structure in memory. I may extend it later to go in the other direction (given a populated datastructure, write a .pgpass). The first question that came to mind is what namespace should I put this under? Is there any precedent for perl modules intended to support postgresql administration? If not, I suggest PostgreSQL::pgpass PostgreSQL sounds like a logical choice. However CPAN - which has product-specific namespaces such as DB2, MySQL, Msql and Oracle, has "Postgres" rather than "PostgreSQL" (though there are only two modules in it, one of which dates from 1998, see http://cpan.org/modules/by-module/Postgres/ ). Ian Barwick ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] perl namespace for postgres specific modules?
I need to write a perl module which will parse a .pgpass file into a reasonable data-structure in memory. I may extend it later to go in the other direction (given a populated datastructure, write a .pgpass). The first question that came to mind is what namespace should I put this under? Is there any precedent for perl modules intended to support postgresql administration? If not, I suggest PostgreSQL::pgpass Thoughts? Drew ---(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: [HACKERS] [PATCHES] extension for sql update
On Fri, Aug 11, 2006 at 10:59:45AM -0400, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > > > Are we sure we don't want the patch for a non-subquery version of SET > > > ROW for 8.2? > > > > > > o Allow UPDATE tab SET ROW (col, ...) = (...) for updating > > > multiple columns > > > > It seems to be moderately useful as a notational convenience for now. > > > > Is it too hard to rip it back out once the full row support arrives? > > That seems speculation at best anyway. > > That's what I was thinking. Glad someone else replied. ;-) If you're looking for votes, +1. I'll gladly take a subset of the SQL standard UPDATE table SET (...) = (...) over having nothing. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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: [HACKERS] 8.2 features status
Jim C. Nasby wrote: > On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote: > > I just threw the trac out there because it was already setup. I don't > > care if anyone uses it or not. Nor am I suggesting that it *should* be used. > > > > Lastly if you review this thread you would see that Andrew and I had > > already decided to wait until after Linux World to actually propose > > something. > > > > It may be Trac it may be something else. For example, I am also looking > > at Launchpad. There is also something very similar to trac that is built > > on ruby on rails that also integrates with mailing lists. > > Does that "rails thing" also have a bug tracker that integrates with > mailing lists? IIRC the show-stopper on a bug tracker was finding one > that allowed people to still use mailing lists. AFAIU the showstopper was that people wanted to be able to _control_ the bugtracker using email only, i.e. not forcing you to open a web browser to do stuff like adding comments or attachments to a bug, or closing, etc. I'm not sure what you have in mind about "integration" between the mailing lists and the bugtracker, because nothing else I can think of makes much sense. I'm always happy to be illuminated :-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote: > I just threw the trac out there because it was already setup. I don't > care if anyone uses it or not. Nor am I suggesting that it *should* be used. > > Lastly if you review this thread you would see that Andrew and I had > already decided to wait until after Linux World to actually propose > something. > > It may be Trac it may be something else. For example, I am also looking > at Launchpad. There is also something very similar to trac that is built > on ruby on rails that also integrates with mailing lists. Does that "rails thing" also have a bug tracker that integrates with mailing lists? IIRC the show-stopper on a bug tracker was finding one that allowed people to still use mailing lists. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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: [HACKERS] V3 protocol vs INSERT/UPDATE RETURNING
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 8/11/06, Tom Lane <[EMAIL PROTECTED]> wrote: >> 4. Treat PORTAL_ONE_RETURNING like PORTAL_UTIL_SELECT rather than >> like PORTAL_ONE_SELECT; that is, execute the query to completion >> on first call and stash the results in a tuplestore until the >> client fetches them. > I agree that it's inefficient, but am trying to think of any other > positive reasons for doing #4 instead. I found a showstopper reason why it has to be done this way: the AFTER TRIGGER code isn't capable of dealing with interleaved execution of different queries (it can basically only track nested queries). Possibly that could be improved in the future, but for 8.2 I think we're stuck with using a tuplestore. One optimization I think might not be too hard is to bypass the tuplestore and stream RETURNING tuples directly to the client if the first Execute for the portal doesn't give a row limit (which is surely the typical case). I don't plan to do that in the first cut though. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Coding style for emacs
Gregory Stark wrote: > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > I use more or less what is in the developers' FAQ (not surprising, since I > > contributed it). It works just fine for me. See > > http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9 > > > > We should probably bring the docs in line with that, unless someone with > > more > > emacs-fu than me has something to add. > > Oh, I've been meaning to email about this. There's a file in the source tree > but it's buggy. The code in your FAQ seems ok, but I prefer the way I've done > it: > > (add-hook 'c-mode-hook > (function > (lambda nil >(if (string-match "pgsql" buffer-file-name) >(progn > (c-set-style "bsd") > (setq c-basic-offset 4) > (setq tab-width 4) > (c-set-offset 'case-label '+) > (setq indent-tabs-mode t) > ) > Would you please send me a patch to FAQ_DEV.html? I can't figure out how this new version would affect what is there now. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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: [HACKERS] Let psql process files with > 4,294,967,295 lines
Patch applied. Thanks. Unnecessary #include file removed. --- David Fetter wrote: > On Sun, Jul 30, 2006 at 05:40:16PM -0400, Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > David Fetter wrote: > > >> This patch changes the data type from unsigned int to unsigned > > >> long long, which is probably not the correct thing in order to > > >> get 64-bit arithmetic, but I figure it's good enough to get a > > >> discussion started. > > > > > The only thing I can tell you is that you should use INT64_FORMAT > > > instead of %lld. > > > > And the datatype should be declared int64, not "long long" which > > doesn't exist everywhere. > > > > Actually you probably want uint64 and UINT64_FORMAT... > > > > regards, tom lane > > I think this fixes it, but I'm unsure how to test it. Two of the > methods mentioned in IRC, attaching with gdb and setting to a value > > 2^32, and setting it directly in some code, seem like OK approaches. > > Cheers, > D > -- > David Fetter <[EMAIL PROTECTED]> http://fetter.org/ > phone: +1 415 235 3778AIM: dfetter666 > Skype: davidfetter > > Remember to vote! [ Attachment, skipping... ] > > ---(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 -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ecpg tests make failed on Win32/MinGW
I have found the cause.
The source file func.pgc is in DOS format, using CRLF(\r\n, or 0x0D0A) as
the newline character(s). That's why I got the output:
$ make func.o
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -g -I./../../include -I../../../.
./../src/interfaces/libpq -I../../include -I../../../../../src/include -I./../..
/include -I../../../../../src/interfaces/libpq -I../../../../../src/include
-I./src/include/port/win32 -DEXEC_BACKEND
"-I../../../../../src/include/port/win32"
-c -o func.o func.c -MMD -MP -MF .deps/func.Po
func.pgc: In function `main':
func.pgc:18: error: missing terminating " character
func.pgc:22: error: `BEGIN' undeclared (first use in this function)
func.pgc:22: error: (Each undeclared identifier is reported only once
func.pgc:22: error: for each function it appears in.)
func.pgc:22: error: syntax error before "RAISE"
func.pgc:22:16: warning: character constant too long for its type
func.pgc:24: error: `RETURN' undeclared (first use in this function)
func.pgc:26: error: `END' undeclared (first use in this function)
func.pgc:26: error: `$test$' undeclared (first use in this function)
func.pgc:26: error: syntax error before "language"
func.pgc:26: error: missing terminating " character
make: *** [func.o] Error 1
Now I change the file to use UNIX format, using LF(\n, or 0x0A) as the
newline character. Everything is OK then:
$ make func.o
../../preproc/ecpg -I./../../include -o func.c -I. func.pgc
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -g -I./../../include -I../../../.
./../src/interfaces/libpq -I../../include -I../../../../../src/include -I./../..
/include -I../../../../../src/interfaces/libpq -I../../../../../src/include
-I./src/include/port/win32 -DEXEC_BACKEND
"-I../../../../../src/include/port/win32"
-c -o func.o func.c -MMD -MP -MF .deps/func.Po
Most of the time, the lexer will recognize differnt kinds of newline
characters in the pgc file (see comments in file pgc.l at about line 237).
But for lines in dollar quoted strings, it will preserve the newline
characters.
And in output_escaped_str() from preproc/output.c, we will replace '\n'
with
'\' and '\n'. Since the input string ends with "\r\n", after the replace, it
becomes '\r', '\', '\n'. That's why I have seen "^M\" in func.c.
Some lines of output from func.c(func.pgc in DOS format, showed in vim):
#line 16 "func.pgc"
^M
^M
{ ECPGdo(__LINE__, 0, 1, NULL, "create function My_Table_Check () returns
trigger as $test$^M\
BEGIN^M\
RAISE WARNING 'Notice: TG_NAME=%, TG WHEN=%', TG_NAME, TG_WHEN;^M\
RETURN NEW;^M\
END; $test$ language plpgsql", ECPGt_EOIT, ECPGt_EORT);
#line 24 "func.pgc"
if (sqlca.sqlwarn[0] == 'W') sqlprint();
#line 24 "func.pgc"
if (sqlca.sqlcode < 0) sqlprint();}
#line 24 "func.pgc"
^M
^M
Lines of output from func.c(func.pgc in UNIX format):
#line 16 "func.pgc"
{ ECPGdo(__LINE__, 0, 1, NULL, "create function My_Table_Check () returns
trigger as $test$\
BEGIN\
RAISE WARNING 'Notice: TG_NAME=%, TG WHEN=%', TG_NAME, TG_WHEN;\
RETURN NEW;\
END; $test$ language plpgsql", ECPGt_EOIT, ECPGt_EORT);
#line 24 "func.pgc"
if (sqlca.sqlwarn[0] == 'W') sqlprint();
#line 24 "func.pgc"
if (sqlca.sqlcode < 0) sqlprint();}
#line 24 "func.pgc"
Should we modify output_escaped_str() to work around this problem?
--
With regards,
William ZHANG
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Coding style for emacs
Andrew Dunstan <[EMAIL PROTECTED]> writes: > I use more or less what is in the developers' FAQ (not surprising, since I > contributed it). It works just fine for me. See > http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.9 > > We should probably bring the docs in line with that, unless someone with more > emacs-fu than me has something to add. Oh, I've been meaning to email about this. There's a file in the source tree but it's buggy. The code in your FAQ seems ok, but I prefer the way I've done it: (add-hook 'c-mode-hook (function (lambda nil (if (string-match "pgsql" buffer-file-name) (progn (c-set-style "bsd") (setq c-basic-offset 4) (setq tab-width 4) (c-set-offset 'case-label '+) (setq indent-tabs-mode t) ) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(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: [HACKERS] snapshot replication with pg_dump
[EMAIL PROTECTED] (Paul Silveira) writes: > Does anyone have any good examples of implementing "snapshot" > replication. I know that PostgreSQL does not have snapshot > replication and that Slony-I is the recomended replication senario > but I've configured it and it seems rather advanced for a shop that > is implementing PostgreSQL for the first time. I have an > application that will be mostly reads and snapshot replication would > probably be simple enough and would work. I was thinking about just > using pg_dump to do the trick because the DB should not get very > large. Does anyone have any advanced examples of doing something > like this? Also, does anyone have any comments they'd like to share > about this... If your database is small, and your needs simple, then using pg_dump to generate "snapshots" is a perfectly reasonable idea. I suppose the primary complication is whether or not you have multiple databases around on the cluster... If you don't, or if they all need to be "snapshotted," you might consider using pg_dumpall, which also creates users and databases. If pg_dumpall is unsuitable, then you'll still need to grab user information that isn't part of pg_dump output... -- (reverse (concatenate 'string "gro.mca" "@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/postgresql.html "This .signature is shareware. Send in $20 for the fully registered version..." ---(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: [HACKERS] V3 protocol vs INSERT/UPDATE RETURNING
On 8/11/06, Tom Lane <[EMAIL PROTECTED]> wrote: Not really. Locks and so forth held by the query would be held till commit in any case, so I don't see much advantage in finishing the query immediately. Very true. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(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: [HACKERS] V3 protocol vs INSERT/UPDATE RETURNING
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 8/11/06, Tom Lane <[EMAIL PROTECTED]> wrote: >> 4. Treat PORTAL_ONE_RETURNING like PORTAL_UTIL_SELECT rather than >> like PORTAL_ONE_SELECT; that is, execute the query to completion >> on first call and stash the results in a tuplestore until the >> client fetches them. > I agree that it's inefficient, but am trying to think of any other > positive reasons for doing #4 instead. Can you think of any other > advantages system-wide to using #4 instead of #3? Not really. Locks and so forth held by the query would be held till commit in any case, so I don't see much advantage in finishing the query immediately. 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: [HACKERS] V3 protocol vs INSERT/UPDATE RETURNING
> 1. Define it as a feature not a bug. People do occasionally ask for > "UPDATE foo ... LIMIT 1" after all. But this is a pretty klugy way of > getting that, and the arguments that say allowing LIMIT on updating > queries would be a bad idea haven't lost their force. Being one of those who was asking for an UPDATE/DELETE with limit, I would be very glad if this would be implemented... it would be a big help for batch-processing data in OLTP environment (no long running queries allowed). I still don't see why would nondeterminism be generally a bad thing when there are applications which don't care about that... Cheers, Csaba. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] V3 protocol vs INSERT/UPDATE RETURNING
Sorry, copied to list. On 8/11/06, Tom Lane <[EMAIL PROTECTED]> wrote: 3. Throw an error (thereby rolling back the incomplete update) if client closes the portal without having run it to completion. Sounds like the most reasonable considering. I'm not averse to it. 4. Treat PORTAL_ONE_RETURNING like PORTAL_UTIL_SELECT rather than like PORTAL_ONE_SELECT; that is, execute the query to completion on first call and stash the results in a tuplestore until the client fetches them. I agree that it's inefficient, but am trying to think of any other positive reasons for doing #4 instead. Can you think of any other advantages system-wide to using #4 instead of #3? -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] V3 protocol vs INSERT/UPDATE RETURNING
I'm looking at modifying the portal execution strategy so that INSERT RETURNING and friends will work when invoked through "extended query" protocol. Currently, INSERT/UPDATE/DELETE queries are always executed under PORTAL_MULTI_QUERY strategy, which runs the portal's queries to completion and discards any results. Obviously that's gotta change. I was considering making a PORTAL_ONE_RETURNING strategy that works just about like PORTAL_ONE_SELECT, but that would have an interesting side effect. In PORTAL_ONE_SELECT, we can execute the query incrementally (if the client sends Execute messages with row limit counts specified), and we don't insist that the client send enough Execute messages to run the query to completion. If applied to a RETURNING query this would mean that a multi-row update might not be executed completely. I can think of a number of possible ways to handle this: 1. Define it as a feature not a bug. People do occasionally ask for "UPDATE foo ... LIMIT 1" after all. But this is a pretty klugy way of getting that, and the arguments that say allowing LIMIT on updating queries would be a bad idea haven't lost their force. 2. Ignore any requested Execute limit in PORTAL_ONE_RETURNING mode. Trivial to implement but violates the protocol specification. 3. Throw an error (thereby rolling back the incomplete update) if client closes the portal without having run it to completion. 4. Treat PORTAL_ONE_RETURNING like PORTAL_UTIL_SELECT rather than like PORTAL_ONE_SELECT; that is, execute the query to completion on first call and stash the results in a tuplestore until the client fetches them. I don't like #1 much, #2 and #3 seem klugy as well, but #4 is pretty inefficient. At the moment I'm thinking #3 is the least bad answer, but does anyone have another idea? 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: [HACKERS] 8.2 features status
Actually I'd *like* to use something better than CVSWeb, because you know what? It sucks and I'd love to have something better. I'd also I am not opposed to actually using taylor or something to do the conversion instead. I just couldn't get it to work. I think the devel version of Trac contains some stuff to be able to handle multiple SCMs. I know there's a Monotone plugin for it at least. Maybe somebody has already written a CVS plugin as well -- I'll have a look. Well that would make life ALOT easier. Launchpad is proprietary. I don't know about the RoR tool you mention, it may be worth having a look at. Launchpad is supposedly releasing their source 10/2006 I believe. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(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: [HACKERS] 8.2 features status
Alvaro Herrera wrote: > > O.k. but no one is suggesting that we use Trac as a bug tracker, or at > > least I wasn't. All I was suggesting was the ability to help viewing of > > specific files as listed dependencies. > > I am suggesting that. I have heard all the old discussions about not > using a bugtracker, but in all fairness, I think some of us have to > create critical mass and get something started. Those who don't want to > use it can choose not to use it, or they can eventually find that yeah, > maybe it's a good idea after all. If no one does anything, nothing will > happen. Agreed. Seems enough people are interested that even if I don't think it will work, it is worth a try. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: > > >>http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql > >> > >>What are you looking at Alvaro? > > > >Exactly that URL, but this wasn't there when I looked. Maybe it was > >being regenerated at that time? > > Yeah it gets regenerated every 4 hours or so. Suggestion -- have it create the new copy in a separate directory and when it's complete, rename the new one to the original name. That way the update is "atomic" and users don't get to see an incomplete repo. > >I don't know what on earth is going on but I surely won't waste my time > >checking that repo again since it seems pretty useless. > > O.k., I am not sure who put oil in your pudding, but nobody is asking > you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually > what *you* should be using. Actually I'd *like* to use something better than CVSWeb, because you know what? It sucks and I'd love to have something better. I'd also like to have a decent bugtracker as well. If both repo and bugtracker are integrated it could be very useful. We almost have that with Trac but since it doesn't work, it's so close as to instill hope but because of the bugs it's useless so it brings frustration instead, which is much worse than if it didn't do either. > >It's pretty damn useful to be able to use the Trac facilities to mark > >tickets as "fixed in revision such-and-such", which allows us to track > >more carefully the bugs fixed and the features added. But if the repo > >is useless, then the rest of Trac loses a lot of its usefulness as well. > > O.k. but no one is suggesting that we use Trac as a bug tracker, or at > least I wasn't. All I was suggesting was the ability to help viewing of > specific files as listed dependencies. I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. Those who don't want to use it can choose not to use it, or they can eventually find that yeah, maybe it's a good idea after all. If no one does anything, nothing will happen. I think the devel version of Trac contains some stuff to be able to handle multiple SCMs. I know there's a Monotone plugin for it at least. Maybe somebody has already written a CVS plugin as well -- I'll have a look. > It may be Trac it may be something else. For example, I am also looking > at Launchpad. There is also something very similar to trac that is built > on ruby on rails that also integrates with mailing lists. Launchpad is proprietary. I don't know about the RoR tool you mention, it may be worth having a look at. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Bison Version
Due to the bug in bison 2.1, I always use version 1.875: http://www.mail-archive.com/bug-bison@gnu.org/msg00718.html ""Christopher Kings-Lynne"" <[EMAIL PROTECTED]> > What version of Bison is currently required to compile HEAD? 1.75 > doesn't seem to work... > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Lastly if you review this thread you would see that Andrew and I had already decided to wait until after Linux World to actually propose something. It is perhaps not surprising, but most of the discussion has been focused on technologies (mailing lists, wikis, bugtrackers, trac, SCM systems, etc.). My view is that these things are at best enablers of good process, but they should not define the processes used. I am trying to spend what little time I can devote to this topic to thinking about the issues I see in human rather than technological terms. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
I do not agree. How you determine what release fixes the bug now? We have web page and mailing list for bug reporting but there is not any relation between bug, patch and release(s). I think bug tracking is necessary if we want move forward. You can completely forget the idea of having an actual bug tracking system. It has been beaten to death over the years. The developers have very specific requirements that no bug tracker currently adheres to. If you are in the mood for a long, never ending soap opera on the topic I suggest you review the archives :) Sincerely, Joshua D. Drake Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(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: [HACKERS] 8.2 features status
http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql What are you looking at Alvaro? Exactly that URL, but this wasn't there when I looked. Maybe it was being regenerated at that time? Yeah it gets regenerated every 4 hours or so. But I don't know why you are ignoring my comments that it's broken. For an example, go here: http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src No one is ignoring you. Note that the DEVELOPERS file shows a revision 5684, message "Typo fix". Click on that 5684. It'll show you two items, revs 23689 and 5684. First problem, where did that 23689 come from? It wasn't there in the parent dir. Now open that changeset (click on the [23689]). Look at the list of files -- it only has errcodes.sgml in it. No DEVELOPERS, which is the file we want to track! Furthermore, it doesn't show any diff at all. O.k. So it isn't perfect. It isn't like I expected to be. However many people find it useful, myself included. I don't know what on earth is going on but I surely won't waste my time checking that repo again since it seems pretty useless. O.k., I am not sure who put oil in your pudding, but nobody is asking you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually what *you* should be using. I would expect that if the SVN/Trac repo were determined to be used it would be used as an entry point and that explicit instructions would also be made that the authoritative source of the code is the CVSWeb repository. Doesn't Trac have a CVS plugin? No, like the rest of the world, Trac has moved on from CVS ;) There are still a lot of projects using CVS. We happen to be one of them. Unfortunately that is true. It's pretty damn useful to be able to use the Trac facilities to mark tickets as "fixed in revision such-and-such", which allows us to track more carefully the bugs fixed and the features added. But if the repo is useless, then the rest of Trac loses a lot of its usefulness as well. O.k. but no one is suggesting that we use Trac as a bug tracker, or at least I wasn't. All I was suggesting was the ability to help viewing of specific files as listed dependencies. Precisely my point. But if the reference doesn't work, then it's just a plain Wiki like any other. I wouldn't want to waste my time on that. I just threw the trac out there because it was already setup. I don't care if anyone uses it or not. Nor am I suggesting that it *should* be used. Lastly if you review this thread you would see that Andrew and I had already decided to wait until after Linux World to actually propose something. It may be Trac it may be something else. For example, I am also looking at Launchpad. There is also something very similar to trac that is built on ruby on rails that also integrates with mailing lists. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] different sort order in windows and linux
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Fri, Aug 11, 2006 at 12:48:27AM -0400, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Do we want to enable a ICU build option in 8.2? > > > > Uh, that wasn't seriously on the table was it? AFAIR we don't have a > > current patch (ie something that applies cleanly to HEAD or near HEAD) > > and I have not seen any discussion about it since March or so. > > Unfortunatly I agree. I was kinda prepared to have a shot at > resurrecting the patch if there was some serious interest but nothing > happened. > > It's way too late in the freeze now. There's still 8.3... OK. The email was in my mailbox and it never got addressed before feature freeze. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] extension for sql update
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Are we sure we don't want the patch for a non-subquery version of SET > > ROW for 8.2? > > > > o Allow UPDATE tab SET ROW (col, ...) = (...) for updating > > multiple columns > > It seems to be moderately useful as a notational convenience for now. > > Is it too hard to rip it back out once the full row support arrives? > That seems speculation at best anyway. That's what I was thinking. Glad someone else replied. ;-) -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: > Alvaro Herrera wrote: > >Jim Nasby wrote: > >>First, +1 on Josh B.'s point about trying out Trac, since it's > >>already up and running. Josh D., can you just turn that on? (BTW, is > >>trac linked off http://commandprompt.com anywhere? I had to google to > >>find it yesterday...) > > > >I just noticed that the code repository on that Trac is broken in more > >ways than I had realized. For starters it doesn't seem to have the 8.1 > >branch or tags (apparently it's out of date). > > It doesn't? > > http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql > > What are you looking at Alvaro? Exactly that URL, but this wasn't there when I looked. Maybe it was being regenerated at that time? But I don't know why you are ignoring my comments that it's broken. For an example, go here: http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src Note that the DEVELOPERS file shows a revision 5684, message "Typo fix". Click on that 5684. It'll show you two items, revs 23689 and 5684. First problem, where did that 23689 come from? It wasn't there in the parent dir. Now open that changeset (click on the [23689]). Look at the list of files -- it only has errcodes.sgml in it. No DEVELOPERS, which is the file we want to track! Furthermore, it doesn't show any diff at all. I have looked at it before and I've found these kinds of problems all over the place. If you mark "follow copies" in the box at the right and then click Update, more broken revisions will appear. It's impossible to actually follow the history of a file, because all the entries are bogus. I don't know what on earth is going on but I surely won't waste my time checking that repo again since it seems pretty useless. > >Doesn't Trac have a CVS plugin? > > No, like the rest of the world, Trac has moved on from CVS ;) There are still a lot of projects using CVS. We happen to be one of them. It's pretty damn useful to be able to use the Trac facilities to mark tickets as "fixed in revision such-and-such", which allows us to track more carefully the bugs fixed and the features added. But if the repo is useless, then the rest of Trac loses a lot of its usefulness as well. > And to be clear, I would only expect that this would be used as a > reference, that is all. The ability to link from the wiki directly to a > source file or changeset could be useful. Precisely my point. But if the reference doesn't work, then it's just a plain Wiki like any other. I wouldn't want to waste my time on that. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Neil Conway napsal(a): However, is there a reason to use Trac beyond the fact that it is already setup? ISTM we only need a wiki, and don't need the other features of Trac, such as the bug tracker. I do not agree. How you determine what release fixes the bug now? We have web page and mailing list for bug reporting but there is not any relation between bug, patch and release(s). I think bug tracking is necessary if we want move forward. Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Bison Version
Christopher Kings-Lynne wrote: What version of Bison is currently required to compile HEAD? 1.75 doesn't seem to work... Bison >= 1.875 has been required for years. That hasn't changed. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bison Version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > What version of Bison is currently required to compile HEAD? 1.75 > doesn't seem to work... 1.875 Search for Bison here: http://projects.commandprompt.com/public/pgsql/browser/trunk/pgsql/doc/src/sgml/installation.sgml - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200608110905 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFE3IEivJuQZxSWSsgRAlflAJ9ZqKPKyrav/Ln7vjSgFzBEyorfgACgw0vJ OMR3lJzf5MP1mhzVdlVDZG4= =Oz63 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] libpq Describe Extension [WAS: Bytea and perl]
On Aug 11 12:51, Greg Sabino Mullane wrote: > > think it would be quite handy to be able to gather information about > > a prepared stmt in later phases of an application. For instance one > > might need to get the parameter and row types of a prepared query > > that he/she isn't created. > > Prepared statements are not visible nor survivable outside of your > session, so this doesn't really make sense. If your application needs > the information, it can get it at prepare time. What about persistent connections? Actually, I can give lots of corner cases to support my idea but they're not that often used. I think, as long as we'll break compatibility, placing Describe facility in the PQprepare() is not the way to go. > >> Anyone have a need to get the result type info during PQprepare? > > > I don't think so. And if one would ever need such an information, can > > reach it quite easily via PQdescribePrepared(). > > That's a good point, however, along with your other arguments. :) I > could live with either way. I'm just declined to break current PQprepare() or to introduce new PGresult-processor functions for a feature (IMHO) that needs its own function. But the general use case is the main fact that'll say the last word. Regards. ---(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
[HACKERS] Bison Version
What version of Bison is currently required to compile HEAD? 1.75 doesn't seem to work... ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] libpq Describe Extension [WAS: Bytea and perl]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > think it would be quite handy to be able to gather information > about a prepared stmt in later phases of an application. For > instance one might need to get the parameter and row types of > a prepared query that he/she isn't created. Prepared statements are not visible nor survivable outside of your session, so this doesn't really make sense. If your application needs the information, it can get it at prepare time. >> Anyone have a need to get the result type info during PQprepare? > I don't think so. And if one would ever need such an information, can > reach it quite easily via PQdescribePrepared(). That's a good point, however, along with your other arguments. :) I could live with either way. - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200608110849 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFE3Hz8vJuQZxSWSsgRAuJuAJ4z/LmnoLOXIoZcdSh0VFYCdBDMlwCfd3HW 8YOwN30Jb8jHGx/OOjWzPaQ= =9tRi -END PGP SIGNATURE- ---(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: [HACKERS] Difference Between record and rowtype
Volkan YAZICI <[EMAIL PROTECTED]> writes: > What's [the difference between] a record (which is a pseudo 'p' type) and > a rowtype (which's a complex 'c' type). The main difference is that you can't declare a table column as having a pseudotype. RECORD is restricted to uses where the system can determine the specific row type from context, whereas a 'c' type is effectively self-contained and will work anywhere. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] snapshot replication with pg_dump
Hello, Does anyone have any good examples of implementing "snapshot" replication. I know that PostgreSQL does not have snapshot replication and that Slony-I is the recomended replication senario but I've configured it and it seems rather advanced for a shop that is implementing PostgreSQL for the first time. I have an application that will be mostly reads and snapshot replication would probably be simple enough and would work. I was thinking about just using pg_dump to do the trick because the DB should not get very large. Does anyone have any advanced examples of doing something like this? Also, does anyone have any comments they'd like to share about this... Thanks in advance, Paul -- View this message in context: http://www.nabble.com/snapshot-replication-with-pg_dump-tf2090351.html#a5761329 Sent from the PostgreSQL - hackers forum at Nabble.com. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] extension for sql update
Bruce Momjian wrote: > Are we sure we don't want the patch for a non-subquery version of SET > ROW for 8.2? > > o Allow UPDATE tab SET ROW (col, ...) = (...) for updating > multiple columns It seems to be moderately useful as a notational convenience for now. Is it too hard to rip it back out once the full row support arrives? That seems speculation at best anyway. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
[HACKERS] Difference Between record and rowtype
Hi, What's [the difference between] a record (which is a pseudo 'p' type) and a rowtype (which's a complex 'c' type). Regards. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
Reinoud van Leeuwen wrote: On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote: I think it is a combination of the two. A wiki could be used to discuss ideas for todos, it could be used to describe TODOs in actual detail, it could used (in conjunction with Trac) to be able to document dependecies for todos... etc. A wiki for *discussion*? I thought email was for that. A wiki is nice to work toghether on a document (in some circumstances). I dont he meant that. A wiki is a good place to summarize an email discussion, not to actually hold a discussion on the wiki (I have seen it done though .. and its not pretty). regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote: > I think it is a combination of the two. A wiki could be used to discuss > ideas for todos, it could be used to describe TODOs in actual detail, it > could used (in conjunction with Trac) to be able to document dependecies > for todos... etc. A wiki for *discussion*? I thought email was for that. A wiki is nice to work toghether on a document (in some circumstances). -- __ "Nothing is as subjective as reality" Reinoud van Leeuwen[EMAIL PROTECTED] http://www.xs4all.nl/~reinoud __ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] libpq Describe Extension [WAS: Bytea and perl]
On Aug 10 11:35, Tom Lane wrote: > Volkan YAZICI <[EMAIL PROTECTED]> writes: > > [ patch to add PQdescribePrepared and PQdescribePortal ] > > After looking this over, I don't see the point of PQdescribePortal, > at least not without adding other functionality to libpq. There is > no functionality currently exposed by libpq that allows creating a > portal (that is, sending a Bind message) without also executing the > portal. And the execution always returns the portal description. > So I don't see why you'd use it. > > PQdescribePrepared is useful though, as it plugs the feature omission > mentioned in the description of PQprepare, namely, you can't find out > what datatype was inferred for a parameter that you didn't specify a > type for. > > My inclination is to add PQdescribePrepared, but leave out > PQdescribePortal until such time as we decide to add functions > to libpq that support separate Bind and Execute operations. > (That might be never, seeing that no one's gotten around to it > since 7.4...) My intention while implementing PQdescribePortal() was to gather information about a portal created by an explicit DECLARE ... CURSOR query. In case of connections are persistenly established with some pool mechanism, it can be handy to be able to learn will be returned row descriptions from an existing portal. > The patch is missing an asynchronous version of PQdescribePrepared. > I'm not real sure what to call it --- the naming conventions we've > used in libpq are not as orthogonal as one could wish. > PQsendDescribePrepared is the best I can manage; anyone have a better > idea? > > Also, we could take a completely different tack, which is to not invent > new functions but instead fold this functionality into PQprepare and > PQsendPrepare. What Volkan's done with this patch is to define the > successful result of PQdescribePrepared as being a PGresult in which > only the number of columns and their datatypes (PQnfields and PQftype) > are meaningful. We could perfectly well use that convention in the > PGresults returned by PQprepare/PQsendPrepare. The upside of this > method is that it wouldn't require an extra network round trip to get > the information (because we'd just include the Describe Statement > request in the original Prepare packet). The downside is that we'd > always spend the time to perform Describe Statement, even if the > application doesn't need it. However I'd expect that time to be > pretty minimal in comparison to the other costs of a Prepare. > > I'm leaning slightly to the fold-it-into-PQprepare way, but am by > no means set on that. Comments anyone? IMHO, it isn't the only use case of Description messages for prepared queries to learn the infered types just after a PQprepare() call. I think it would be quite handy to be able to gather information about a prepared stmt in later phases of an application. For instance one might need to get the parameter and row types of a prepared query that he/she isn't created. If we'd place Describe message facility into PQprepare(), then we'll just lose that functionality of the feature. OTOH, moving Describe data processing into the PQprepare() is fairly conventional for introducing a new functionality at the same time keeping the API consistent without raising any compatibility problems. But AFAICS, that's not possible without giving over one of the features of Describe messages for prepared statements: parameter types information or row types information. Because, if we consider placing Describe facility into PQprepare(), client would have to issue two distinct PQgetResult() calls; one for parameter types and another one for row types. On Aug 10 12:31, Tom Lane wrote: > So another theory about how this ought to work is that PQprepare's > result PGresult ought to carry the column name/type info where PQfname > and PQftype can get them, and then we'd have to have two new > PGresult-inspection functions to pull out the separately stored > parameter-datatype info. Yes, that's another feasible approach to the solution. But this one too has its own PITAs as the one mentioned above. > This seems much cleaner than overloading the meaning of PQftype, but > OTOH it's yet a few more cycles added to the execution cost of > PQprepare. I think, placing Describe facility into PQprepare() will just obfuscate the problem. In every approach we tried to place Describe into PQprepare(), we needed to introduce new functions or broke compatibility with the exisiting versions. ISTM, Describe features having their own functions is the only fair solution I could come up with. > Anyone have a need to get the result type info during PQprepare? I don't think so. And if one would ever need such an information, can reach it quite easily via PQdescribePrepared(). Regards. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Forcing current WAL file to be archived
On Thu, 2006-08-10 at 08:57 -0400, Tom Lane wrote: > Anyway, after further thought I've concluded that we really should > supply something that returns the Insert pointer, as this would be > useful for debugging and system-monitoring purposes. It's clear however > that we also need something that returns the Write pointer, as that's > what's needed for partial log-shipping. > So my vote is for two > functions, both read-only (and hence not superuser-only). Thats probably the most important consideration. > Not sure > what to name them exactly. pg_current_xlog_location() - gives the write pointer i.e. the offset up to which you can read() the xlog file and trust what it tells you pg_current_wal_insert_pointer() - gives the insert pointer :-) Named sufficiently differently that there is no confusion between them. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
