Re: [HACKERS][PATCHES] odd output in restore mode
Heikki Linnakangas wrote: Andrew Dunstan wrote: - or maybe provide a .bat file or perl script that would work as na archive_command on Windows. We're not talking about archive_command. We're talking about the thing that copies files to the directory that pg_standby polls. Er, that's what the archive_command is. Look at the pg_standby docs and you'll see that that's where we're currently recommending use of windows copy. Perhaps you're confusing this with the restore_command? 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: [HACKERS][PATCHES] odd output in restore mode
Greg Smith wrote: On Wed, 23 Jul 2008, Kevin Grittner wrote: In our scripts we handle this by copying to a temp directory on the same mount point as the archive directory and doing a mv to the archive location when the copy is successfully completed. I think that this even works on Windows. Could that just be documented as a strong recommendation for the archive script? This is exactly what I always do. I think the way cp is shown in the examples promotes what's really a bad practice for lots of reasons, this particular problem being just one of them. I've been working on an improved archive_command shell script that I expect to submit for comments and potential inclusion in the documentation as a better base for other people to build on. This is one of the options for how it can operate. It would be painful but not impossible to convert a subset of that script to run under Windows as well, at least enough to cover this particular issue. A Perl script using the (standard) File::Copy module along with the builtin function rename() should be moderately portable. It would to be nice not to have to maintain two scripts. 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] pg_dump additional options for performance
Joshua D. Drake wrote: Agreed but that is a problem I understand with a solution I don't. I am all eyes on a way to fix that. One thought I had and please, be gentle in response was some sort of async transaction capability. I know that libpq has the ability to send async queries. Is it possible to do this: send async(copy table to foo) send async(copy table to bar) send async(copy table to baz) Where all three copies are happening in the background? IIRC, libpq doesn't let you have more than one async query active at one time. 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: [HACKERS][PATCHES] odd output in restore mode
Kevin Grittner wrote: Heikki Linnakangas [EMAIL PROTECTED] wrote: We really need a more reliable way of detecting that a file has been fully copied. In our scripts we handle this by copying to a temp directory on the same mount point as the archive directory and doing a mv to the archive location when the copy is successfully completed. I think that this even works on Windows. Could that just be documented as a strong recommendation for the archive script? Needs testing at least. If it does in fact work then we can just adjust the docs and be done - or maybe provide a .bat file or perl script that would work as na archive_command on Windows. 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] pg_dump additional options for performance
Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: I also suggested having three options --want-pre-schema --want-data --want-post-schema so we could ask for any or all parts in the one dump. --data-only and --schema-only are negative options so don't allow this. (I don't like those names either, just thinking about capabilities) Maybe invert the logic? --omit-pre-data --omit-data --omit-post-data Not wedded to these either, just tossing out an idea... Please, no. Negative logic seems likely to cause endless confusion. I'd even be happier with --schema-part-1 and --schema-part-2 if we can't find some more expressive way of designating them. 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] [HACKERS] Solaris ident authentication using unix domain sockets
Josh Berkus wrote: Tom, Indeed. If the Solaris folk feel that getupeercred() is insecure, they had better explain why their kernel is that broken. This is entirely unrelated to the known shortcomings of the ident IP protocol. The Solaris security kernel folks do, actually. However, there's no question that TRUST is inherently insecure, and that's what people are going to use if they can't get IDENT to work. I think I'd pose a slightly different question from Tom. Do the Solaris devs think that their getupeercred() is more insecure than the more or less equivalent calls that we are doing on Linux and *BSD for example? I suspect they probably don't ;-) 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] [HACKERS] Solaris ident authentication using unix domain sockets
Robert Treat wrote: On Thursday 03 July 2008 14:01:22 Tom Lane wrote: Garick Hamlin [EMAIL PROTECTED] writes: I have a patch that I have been using to support postgresql's notion of ident authentication when using unix domain sockets on Solaris. This patch basically just adds support for using getupeercred() on Solaris so unix sockets and ident auth works just like it does on Linux and elsewhere. Cool. Hmm... I've always been told that Solaris didn't support this because the Solaris developers feel that IDENT is inherently insecure. If that is more than just a philosphical opinion, I wonder if there should be additional hurdles in place to enable this on that platform. Note that isn't an objection from me, though I'm curious if any of the Sun guys want to chime in on this. We don't actually use the Ident protocol for Unix sockets on any platform. AIUI, this patch just implements what we do on platforms like Linux or *BSD. 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] variadic function support
Pavel Stehule wrote: I afraid so Java syntax isn't good inspiration http://www.java-tips.org/java-se-tips/java.lang/using-the-varargs-language-feature.html http://www.clanproductions.com/java5.html they use symbol ... like specific synonym to []. public Method getMethod(String name, Class... parameterTypes) Well, ... is really more the equivalent of your variadic keyword, I think. public Method getMethod(String name, Class[] ... parameterTypes) would mean each variadic argument would be an array of Class. 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] variadic function support
Pavel Stehule wrote:
Hello
this patch enhance current syntax of CREATE FUNCTION statement. It
allows creating functions with variable number of arguments. This
version is different than last my patches. It doesn't need patching
PL. Basic idea is transformation of real arguments (related to
declared variadic argument) to array. All changes are mostly in
parser.
Demo:
CREATE FUNCTION public.least(double precision[]) RETURNS double precision AS $$
SELECT min($1[i])
FROM generate_subscripts($1,1) g(i)
$$ LANGUAGE SQL VARIADIC;
SELECT public.least(3,2,1);
least
---
1
(1 row)
SELECT public.least(3,2,1,0,-1);
least
---
-1
CREATE FUNCTION concat(varchar, anyarray) RETURNS varchar AS $$
SELECT array_to_string($2, $1);
$$ LANGUAGE SQL VARIADIC;
SELECT concat('-',2008,10,12);
concat
2008-10-12
(1 row)
And what about a function that takes 2 arrays as arguments?
This proposal strikes me as half-baked. Either we need proper and full
support for variadic functions, or we don't, but I don't think we need
syntactic sugar like the above (or maybe in this case it's really
syntactic saccharine).
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] variadic function support
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
What would you consider proper and full support?
I don't know. But this doesn't feel like it.
That's a fairly weak argument for rejecting a patch that provides a
feature many people have asked for.
OK. Let me be a bit more specific. I think (forcing myself to be a bit
more analytic than I have been up to now) my main objection is that the
variadic part of the parameters should be marked explicitly in the
formal parameter list.
I don't mind having it limited to a single typed array - as you say we
probably don't want someone implementing sprintf.
But if I have
foo( a text, b int[])
it looks odd if both these calls are legal:
foo('a',1,2,3,)
foo('a',ARRAY[1,2,3])
which I understand would be the case with the current patch.
I'm also still curious to know how the following would be handled:
foo(a text[], b text[])
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] variadic function support
Tom Lane wrote: Your point about the syntax is good though. It would be better if the syntax were like create function foo (a text, variadic b int[]) or maybe even better create function foo (a text, variadic b int) since (a) this makes it much more obvious to the reader what the function might match, and (b) it leaves the door open for marking multiple parameters as variadic, if we can figure out what that means. Yes. I understand from the family Java expert that (surface syntax issues aside) the second is similar to the way Java does this, in fact, so there's some precedent. That would mean that your first would actually mean each variadic arg has to be an array of ints, which we might well want to provide for. So with that modification I'll be lots happier with the feature. 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] doc patch - archive/restore_command on windows
ITAGAKI Takahiro wrote: I found the examples of documentation about archive_command and restore_command for Windows are incorrect or improper. - copy doesn't accept / (slash) as a path separator. We should use \\ (double backslash) for the purpose. - Windows path is typically starts with a drive letter (C:\\). - We'd better to quote a whole path, not only the last filename with double-quotes. It can work, but is not a windows manner. As previously discussed, we should probably stop recommending use of the Windows copy command altogether, and recommend use of GnuWin32 cp instead, for archive_command. The latter does behave sanely w.r.t. forward slashes. 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] Tentative patch for making DROP put dependency info in DETAIL
Tom Lane wrote: multi-object DROP IF NOT EXISTS would fail to perform as expected. Surely this would be a noop :-) 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] Feature: give pg_dump a WHERE clause expression
Tom Lane wrote: Davy Durham [EMAIL PROTECTED] writes: So, if this patch is not acceptable as-is, what would you feel about this: I could enhance the -t/--table=NAME option to accept more than a simple NAME. Rather it could accept something in the form: --table=table_name:where-clause expression Well, that would at least address the complaint that it doesn't scale to multiple tables, but the whole thing still seems like a frammish that will never see enough use to justify maintaining it. (BTW, what will you do with a table whose name contains a colon?) ISTM this would be better off waiting until we turn large parts of pg_dump into a library, as has been often discussed, at which point it should be relatively simple to write a custom client to do what the OP wants. I agree that it does not at all belong in pg_dump. 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] Feature: give pg_dump a WHERE clause expression
daveg wrote: ISTM this would be better off waiting until we turn large parts of pg_dump into a library, as has been often discussed, at which point it should be relatively simple to write a custom client to do what the OP wants. I agree that it does not at all belong in pg_dump. I can't imagine many of my clients ever writing another C program or even being willing to pay me to do so. While modularizing pg_dump is a fine idea, I don't think it addresses the same set of use cases and users as this proposal. It's not clear to me that your use case is very compelling. Does your foreign database not support import via CSV or XML? Postgres can now produce both of these for any arbitrary query. 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] [HACKERS] use of pager on Windows psql
Bruce Momjian wrote:
Andrew Dunstan wrote:
Not sure why ware are not. Should we enabled that code on Win32 and see
how it works? Can you test it? Was it some MinGW limitation? I do see
isatty() being used on lots of platforms.
This is kind of odd. Ah, I bet it came from libpq's PQprint(), which I
think we had working on Win32 long before we had psql working and
perhaps I copied it from there. I don't see the Win32 checks around
isatty() anywhere else.
In fact, it looks to me like it would be much more sensible to #include
settings.h and then simply test pset.notty for all platforms.
Yes, we could do that but does the isatty() value ever change while psql
is running? When you do '\g filename' does stdout then have isatty as
false?
Good point. I think the best thing would just be to remove the #ifndef
WIN32 / #endif lines
OK, patch applied to remove the Win32 test in both places.
This broke the buildfarm and finally explains the following kluge which
has been puzzling me for four years:
/*
* for some reason MinGW (and MSVC) outputs an extra newline, so
this
* suppresses it
*/
#ifndef WIN32
fputc('\n', fout);
#endif
I have removed the kluge (and yes, I tested it).
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] [HACKERS] use of pager on Windows psql
Bruce Momjian wrote:
This broke the buildfarm and finally explains the following kluge which
has been puzzling me for four years:
/*
* for some reason MinGW (and MSVC) outputs an extra newline, so
this
* suppresses it
*/
#ifndef WIN32
fputc('\n', fout);
#endif
I have removed the kluge (and yes, I tested it).
Oh, that kluge. Why did the isatty() addition fix this? Was the pager
being used on Win32 for the regression tests and somehow eating a line
or something?
It apparently produced an extra line which we had compensated for with
the kluge (without really understanding why we had to).
Anyway, all is good now, as the buildfarm shows.
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] libpq object hooks
Merlin Moncure wrote: Also, even if varargs are safe they'd be notationally unpleasant in the extreme. varargs are just a PITA to work with --- you'd have to do all the decoding in the first-level hook routine, even for items you weren't going to use. With something like the above all you need is a switch() and some pointer casts. Switch, plus struct (basically a union) will do the trick nicely. Can it be a formal union, or is it better as a void*? The main issue was how what we called the 'hook data' was passed back and forth. We'll get a patch up. All of this is getting quite a long way from what was in the commitfest queue. Do we still want to try to get this in this cycle, or should it be marked returned to author for more work? 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] libpq object hooks
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: All of this is getting quite a long way from what was in the commitfest queue. Do we still want to try to get this in this cycle, or should it be marked returned to author for more work? So far I think it still falls within the category of allowing the author to revise his work. I don't want to hold commitfest open waiting on revisions of this patch, but as long as there's still other stuff being worked through I don't see why they can't keep trying. Just for the record, I would really like to close this fest before PGCon starts. We still have a couple more days to get it done. Apart from this one only two have not been claimed: . Map Forks . TRUNCATE TABLE with IDENTITY 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] Patch to change psql default banner v6
Joshua D. Drake wrote: O.k. I am not trying to start an argument here but... I already sent 6 revisions of this patch that received comments and had thorough review via Alvaro. I even took into account Tom's original comments from the previous thread. This much effort on something so simple makes it not worth the effort in the first place. Welcome to UI development. There is always *far* more argument of minor matters of appearance than over anything else, in my experience. 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] libpq object hooks
Tom Lane wrote: Merlin Moncure [EMAIL PROTECTED] writes: The problem is the functions PQhookData(conn, hookname) and PQresultHookData(result, hookName). We need these to work in functions that are not callbacks. If we eliminate hookname completely, there is no way for libpq to know which private state we are asking for. Well, depending on a hook name for this is broken-by-design anyway, because there is no way for two independently written libraries to be sure they don't choose conflicting hook names. So the need for a hook name has to go away. It might work to use the address of the hook callback function as a key for retrieving the associated void * pointer. You'd need to not register the same callback function more than once per object, but from what I gather here you don't need to. Or else have the library return a unique handle when registering hooks, rather than supplying a hook name. 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] Patch to change psql default banner v6
David Fetter wrote: I hate to bike-shed this even further, but I'd like to make those incompatibility messages just go away by making 8.4's psql (and all those going forward) support every living version of Postgres at the time of their release, so 8.4's psql would be able to talk seamlessly to Postgres 7.4 :) I think you must have been out in the sun too long. Just look at the pg_dump code if you want something of an idea of what this would involve. 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] Patch to change psql default banner v6
David Fetter wrote: On Thu, May 15, 2008 at 06:55:31PM -0400, Andrew Dunstan wrote: David Fetter wrote: I hate to bike-shed this even further, but I'd like to make those incompatibility messages just go away by making 8.4's psql (and all those going forward) support every living version of Postgres at the time of their release, so 8.4's psql would be able to talk seamlessly to Postgres 7.4 :) I think you must have been out in the sun too long. One thing I really treasure about working on the Postgres project is frank feedback. :) I know you know me well enough to realise there was an implied smiley ;-) Just look at the pg_dump code if you want something of an idea of what this would involve. Given that each previous version tied backslash commands to some particular chunk of SQL, what would be the problem with either immediately or lazily setting those to the chunks of SQL already present in previous versions? First, this is not a cost free exercise - it increases code complexity enormously. Second, it's not nearly as easy as that: . new commands have been added . postgres features have been added . catalogs have changed Among other things, help and indeed the available command set would have to become server version sensitive. And you would greatly increase the bar for anyone wanting to add a new command - now they (or someone) would have to work out how the command would or might work n versions back, not just with the current dev version. Doing it lazily isn't acceptable - if we promise \command compatibility with previous server versions then we need to deliver it to the maximum extent possible, and if we don't promise it there's no point in doing this. And, as Tom says, it has nothing really to do with this patch. 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] Patch to change psql default banner v6
Alvaro Herrera wrote: Andrew Dunstan wrote: Second, it's not nearly as easy as that: . new commands have been added . postgres features have been added . catalogs have changed Well, this just means a different piece of SQL needs to be sent for a command depending on the server version, right? It's not like that's tremendously different. The nice thing about most \X commands is that they embed everything they need in a bunch of SQL, and they don't need much else in C code. So it's not all that difficult. And for commands that have been added later, an initial version could just say this server version does not support this command. It would be already a huge improvement. Probably the biggest change would be to support versions that did not have schemas, but I think it would be OK to punt on that. We already stopped supporting 7.2 anyway. Have at it then. Prove me wrong. 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] libpq object hooks
Alvaro Herrera wrote: Andrew Dunstan escribió: The thing that is a bit disturbing is that the whole style of this scheme is very different from the fairly simple APIs that the rest of libpq presents. It's going to make libpq look rather odd, I think. I would have felt happier if the authors had been able to come up with a simple scheme to add API calls to export whatever information they needed, rather than using this callback scheme. I'm not sure I understand this point. Remember that this is here to support the libpqtypes library. There doesn't seem to be a way for an API such as you describe to work. That might well be true. The issue then becomes Do we want to add something with this flavor to libpq? I take it Bruce's answer is No, at least until he has seen more evidence of general usefulness. I think we need to make a decision on this before anyone wastes any more time. It should be noted that while this feels slightly foreign, it isn't hugely invasive, unlike the previous effort - it's only a few hundred lines of new code. If we reject this, presumably the authors will have no alternative than to offer libpqtypes as a patch to libpq. ISTM that we're then asking them to climb over a fairly high hurdle. On the one hand we want them to demonstrate that there's demand for their tool and on the other we make it difficult to distribute and deploy. Second, the hook names are compared case insensitively and by linear search. I don't see any justification for using case insensitive names for hooks in a C program, so I think that part should go. And if we expect to keep anything other than trivial numbers of hooks we should look at some sort of binary or hashed search. Keep in mind that the original patch supported a single hook being registered. Perhaps we could dream about having a couple of hooks registered, but turning into hashed search would seem to be overkill, at least for now. (If hooking into libpq is truly successful we can always improve it later -- it's not an exported detail of the API after all.) Right, it was more the case insensitive part that bothered me. 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] column level privileges
Tom Lane wrote: I'm not sure where we go from here. Your GSOC student has disappeared, right? Is anyone else willing to take up the patch and work on it? No, he has not disappeared at all. He is going to work on fixing issues and getting the work up to SQL99 level. Your review should help enormously. Stephen, perhaps you would like to work with him. 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] Fix \dT enum in psql
David Fetter wrote: Folks, In psql, \dT doesn't show the elements for enums. Please find patch vs. CVS TIP attached which fixes this per the following TODO item: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php I notice that this patch adds an Elements column to the output of \dT, which will only be used by enum types. That seems rather ... cluttered. 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] Fix \dT enum in psql
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I notice that this patch adds an Elements column to the output of \dT, which will only be used by enum types. That seems rather ... cluttered. But it'll only be in \dT+ anyway, no? Not in this patch. 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] Fix \dT enum in psql
David Fetter wrote: On Sun, May 04, 2008 at 07:49:25PM -0400, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: But it'll only be in \dT+ anyway, no? Not in this patch. Hmmm ... given that a long list of enum members would bloat the output quite a lot, I think I'd vote for putting it in \dT+. Here's one where it's only in \dT+ Yeah. Committed. 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] [HACKERS] Multiline privileges in \z
Brendan Jurd wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 18, 2008 at 2:37 AM, Tom Lane wrote: The function names in the patch need schema-qualification in case pg_catalog is not first in the search path. Ah, yes. I should have seen that. Thanks Tom. New version attached with schema-qualification. Committed with slight editorialization and a consequent docs change. 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] [COMMITTERS] pgsql: Sigh ...
Peter Eisentraut wrote: Andrew Dunstan wrote: This patch should fix things for both sets of changes. And it demonstrates pretty much what you need to do for config options for MSVC. Btw., it is quite easily possible to use the autom4te tracing facility to parse the configure.ac file, in case you are interested in generating some of the Windows build code automatically. For example: $ autoconf -t 'AC_ARG_ENABLE:$1' configure.in integer-datetimes nls shared rpath spinlocks debug profiling dtrace segmented-files depend cassert thread-safety thread-safety thread-safety-force largefile Let me know if you want to do something with that. Yeah, maybe. Let's fix the issue pg_config.h.win32 that Tom raised first. 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] [HACKERS] Multiline privileges in \z
Brendan Jurd wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 18, 2008 at 2:37 AM, Tom Lane wrote: The function names in the patch need schema-qualification in case pg_catalog is not first in the search path. Ah, yes. I should have seen that. Thanks Tom. New version attached with schema-qualification. Wouldn't this expression: pg_catalog.array_to_string(c.relacl, chr(10)) be better expressed as pg_catalog.array_to_string(c.relacl, E'\n') ? Quoted inside a C literal, the backslash would have to be doubled, of course. 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] [COMMITTERS] pgsql: Sigh ...
Tom Lane wrote:
However, all the values are hardcoded, so nothing in it should relate to
settings that come from configure, I believe. These should be dealt with
in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).
FYI, I'm about to commit changes moving XLOG_BLCKSZ and XLOG_SEG_SIZE
into the domain of configurable stuff, too.
This patch should fix things for both sets of changes. And it
demonstrates pretty much what you need to do for config options for MSVC.
If there's no objection I will apply shortly.
cheers
andrew
Index: src/include/pg_config.h.win32
===
RCS file: /cvsroot/pgsql/src/include/pg_config.h.win32,v
retrieving revision 1.54
diff -c -r1.54 pg_config.h.win32
*** src/include/pg_config.h.win32 2 May 2008 03:41:46 - 1.54
--- src/include/pg_config.h.win32 2 May 2008 22:04:37 -
***
*** 37,51
/* The alignment requirement of a `short'. */
#define ALIGNOF_SHORT 2
- /* Size of a disk block --- this also limits the size of a tuple. You can set
-it bigger if you need bigger tuples (although TOAST should reduce the need
-to have large tuples, since fields can be spread across multiple tuples).
-BLCKSZ must be a power of 2. The maximum possible value of BLCKSZ is
-currently 2^15 (32768). This is determined by the 15-bit widths of the
-lp_off and lp_len fields in ItemIdData (see include/storage/itemid.h).
-Changing BLCKSZ requires an initdb. */
- #define BLCKSZ 8192
-
/* Define to the default TCP port number on which the server listens and to
which clients will try to connect. This can be overridden at run-time, but
it's convenient if your clients have the right default compiled in.
--- 37,42
***
*** 600,618
your system. */
/* #undef PTHREAD_CREATE_JOINABLE */
- /* RELSEG_SIZE is the maximum number of blocks allowed in one disk file. Thus,
-the maximum size of a single file is RELSEG_SIZE * BLCKSZ; relations bigger
-than that are divided into multiple files. RELSEG_SIZE * BLCKSZ must be
-less than your OS' limit on file size. This is often 2 GB or 4GB in a
-32-bit operating system, unless you have large file support enabled. By
-default, we make the limit 1 GB to avoid any possible integer-overflow
-problems within the OS. A limit smaller than necessary only means we divide
-a large relation into more chunks than necessary, so it seems best to err
-in the direction of a small limit. A power-of-2 value is recommended to
-save a few cycles in md.c, but is not absolutely required. Changing
-RELSEG_SIZE requires an initdb. */
- #define RELSEG_SIZE 131072
-
/* The size of a `size_t', as computed by sizeof. */
#define SIZEOF_SIZE_T 4
--- 591,596
Index: src/tools/msvc/Solution.pm
===
RCS file: /cvsroot/pgsql/src/tools/msvc/Solution.pm,v
retrieving revision 1.40
diff -c -r1.40 Solution.pm
*** src/tools/msvc/Solution.pm 21 Apr 2008 18:37:28 - 1.40
--- src/tools/msvc/Solution.pm 2 May 2008 22:04:39 -
***
*** 34,39
--- 34,56
die XML requires both XSLT and ICONV\n;
}
}
+ $options-{blocksize} = 8
+ unless $options-{blocksize}; # undef or 0 means default
+ die Bad blocksize $options-{blocksize}
+ unless grep {$_ == $options-{blocksize}} (1,2,4,8,16,32);
+ $options-{segsize} = 1
+ unless $options-{segsize}; # undef or 0 means default
+ # only allow segsize 1 for now, as we can't do large files yet in windows
+ die Bad segsize $options-{segsize}
+ unless $options-{segsize} == 1;
+ $options-{wal_blocksize} = 8
+ unless $options-{wal_blocksize}; # undef or 0 means default
+ die Bad wal_blocksize $options-{wal_blocksize}
+ unless grep {$_ == $options-{wal_blocksize}} (1,2,4,8,16,32,64);
+ $options-{wal_segsize} = 16
+ unless $options-{wal_segsize}; # undef or 0 means default
+ die Bad wal_segsize $options-{wal_segsize}
+ unless grep {$_ == $options-{wal_segsize}} (1,2,4,8,16,32,64);
return $self;
}
***
*** 116,122
print O #define USE_LDAP 1\n if ($self-{options}-{ldap});
print O #define HAVE_LIBZ 1\n if ($self-{options}-{zlib});
print O #define USE_SSL 1\n if ($self-{options}-{openssl});
! print O #define ENABLE_NLS 1\n if ($self-{options}-{nls});
if ($self-{options}-{float4byval})
{
--- 133,148
print O #define USE_LDAP 1\n if ($self-{options}-{ldap});
print O #define HAVE_LIBZ 1\n if ($self-{options}-{zlib});
print O #define USE_SSL 1\n if ($self-{options}-{openssl});
! print O #define ENABLE_NLS 1\n if ($self-{options}-{nls});
!
! print O #define BLCKSZ ,1024 * $self-{options}-{blocksize},\n;
! print O #define RELSEG_SIZE ,
! (1024 / $self-{options}-{blocksize}) *
!
Re: [PATCHES] [COMMITTERS] pgsql: Sigh ...
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
! print O #define RELSEG_SIZE ,
! (1024 / $self-{options}-{blocksize}) *
! $self-{options}-{segsize} * 1024, \n;
This doesn't look quite right; unless the arithmetic is being done in
floating point? I had it like this in configure.in:
RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
blocksize is one of (1,2,4,8,16,32) so it should always be a factor of
1024 unless my arithmetic is awry. I did it that way because I dislike
expressions with unbracketed mixed operations - they make me think too
much.
Also it looks like you missed adding segsize to the config.pl comments.
That's deliberate - we are currently only allowing a value of 1 here, so
I don't see any point in putting it in the sample config file, even as a
comment. When we enable other seg sizes we can add it to the sample file.
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] [COMMITTERS] pgsql: Sigh ...
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
This doesn't look quite right; unless the arithmetic is being done in
floating point? I had it like this in configure.in:
RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
blocksize is one of (1,2,4,8,16,32) so it should always be a factor of
1024 unless my arithmetic is awry. I did it that way because I dislike
expressions with unbracketed mixed operations - they make me think too
much.
Well, if you dislike the original on style grounds, you should change it
to match. Doing the same thing in two different ways in two places
isn't good.
OK, done. Patch applied with that addition (it was time I deployed
autoconf 2.61 anyway).
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] Fix \dT enum in psql
David Fetter wrote: Folks, In psql, \dT doesn't show the elements for enums. Please find patch vs. CVS TIP attached which fixes this per the following TODO item: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php I don't have a particular problem with this patch - indeed the query in it looks eerily familiar :-) However, I'm wondering if we should wait until a possible rework of the mechanics of enums as recently discussed? Or we could put it in and that way it would have to be redone when enums are rejigged. 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
[PATCHES] column level privileges
(try 2) Here is an updated patch that applies to HEAD. I will update the wiki. (What is the maximum attachment size that -patches will accept?) cheers andrew I wrote: This patch by Golden Lui was his work for the last Google SoC. I was his mentor for the project. I have just realised that he didn't send his final patch to the list. I guess it's too late for the current commit-fest, but it really needs to go on a patch queue (my memory on this was jogged by Tom's recent mention of $Subject). I'm going to see how much bitrot there is and see what changes are necessary to get it to apply. - Here is a README for the whole patch. According to the SQL92 standard, there are four levels in the privilege hierarchy, i.e. database, tablespace, table, and column. Most commercial DBMSs support all the levels, but column-level privilege is hitherto unaddressed in the PostgreSQL, and this patch try to implement it. What this patch have done: 1. The execution of GRANT/REVOKE for column privileges. Now only INSERT/UPDATE/REFERENCES privileges are supported, as SQL92 specified. SELECT privilege is now not supported. This part includes: 1.1 Add a column named 'attrel' in pg_attribute catalog to store column privileges. Now all column privileges are stored, no matter whether they could be implied from table-level privilege. 1.2 Parser for the new kind of GRANT/REVOKE commands. 1.3 Execution of GRANT/REVOKE for column privileges. Corresponding column privileges will be added/removed automatically if no column is specified, as SQL standard specified. 2. Column-level privilege check. Now for UPDATE/INSERT/REFERENCES privilege, privilege check will be done ONLY on column level. Table-level privilege check was done in the function InitPlan. Now in this patch, these three kind of privilege are checked during the parse phase. 2.1 For UPDATE/INSERT commands. Privilege check is done in the function transformUpdateStmt/transformInsertStmt. 2.2 For REFERENCES, privilege check is done in the function ATAddForeignKeyConstraint. This function will be called whenever a foreign key constraint is added, like create table, alter table, etc. 2.3 For COPY command, INSERT privilege is check in the function DoCopy. SELECT command is checked in DoCopy too. 3. While adding a new column to a table using ALTER TABLE command, set appropriate privilege for the new column according to privilege already granted on the table. 4. Allow pg_dump and pg_dumpall to dump in/out column privileges. 5. Add a column named objsubid in pg_shdepend catalog to record ACL dependencies between column and roles. 6. modify the grammar of ECPG to support column level privileges. 7. change psql's \z (\dp) command to support listing column privileges for tables and views. If \z(\dp) is run with a pattern, column privileges are listed after table level privileges. 8. Regression test for column-level privileges. I changed both privileges.sql and expected/privileges.out, so regression check is now all passed. pg_colpriv_version_0.4-20080421.patch.gz Description: GNU Zip compressed data -- 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] Text - C string
Tom Lane wrote: Brendan Jurd [EMAIL PROTECTED] writes: If we don't want to meddle with xmltype/bytea/VarChar at all, we'll have to revert those changes, and I'll have to seriously scale back the cleanup patch I was about to post. Still not sure where we stand on the above. To cast, or not to cast? I dunno. I know there was previously some handwaving about representing XML values in some more intelligent fashion than a plain text string, but I have no idea if anyone is likely to do anything about it in the foreseeable future. It seems very unlikely to me. 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] Suppress compiler warnings on mingw
Applied, Thanks. wiki updated. cheers andrew ITAGAKI Takahiro wrote: Peter Eisentraut [EMAIL PROTECTED] wrote: Then try using %lu and no casts. That should get rid of the warnings the proper way. Ok, I rewrote it to use %lu for format strings. Jeremy Drake [EMAIL PROTECTED] wrote: sizeof(DWORD) is always 4, even on 64-bit windows. sizeof(long) is also always 4. I got it. This change will work on 64-bit windows, because DWORD is defined as 'unsigned long' there, too. We need to support LLP64 compliers in advance, though. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- 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] MSVC build broken with perl 5.10
Zeugswetter Andreas OSB SD wrote:
Magnus Hagander wrote:
I just tried the MSVC build on a system with ActiveState Perl 5.10,
and
it doesn't work. Some quick debugging before I downgraded to 5.8
showed
that this regexp in Project.pm line 262:
my $replace_re = qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*:
)?\$(\([^\)]+\))\/(.*)\/[^\/]+$};
matches things properly using Perl 5.8 in for example
src/bin/initdb/Makefile (matches a total of around 10 Makefiles), but
in 5.10 it simply does not match anything...
Any perl guru out there who can comment on why? ;-)
The answer is actually simple, the \n needs the multiline modifier,
and thus the m needs to be part of the quote-like operator.
The perl doc states:
This operator quotes (and possibly compiles) its STRING
(it seems 5.8 did not compile, but 5.10 does)
I feel that it is rather not a perl bug, and that the modifiers need to
be put
on the qr{}. I do not quite see why this re needs to be multiline in the
first place,
but I have not touched that in the attached patch, that is ready to
apply.
(modification works in perl 5.6, 5.8, 5.10)
Thanks, that makes sense. I wonder how it ever worked before. Anyway,
patch applied back as far as 8.2.
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] Fix for win32 stat() problems
Magnus Hagander wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Trying to prepare a patch that does it the normal way, but so far I'm failing rather miserably. The *struct* stat is already redefined on win32, so whenever I try #undef or so it conflicts with that :-( Since there is no way to #undef only the parametrized version. I don't follow ... there's no such redefinition in our code AFAICS. Do you mean that the system header files declare it as a macro? Yes. How about #defining safe_stat to be pg_win32_safe_stat on Windows and simply stat elsewhere? Then use safe_stat at the places you consider critical. 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] Concurrent psql patch
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: This has been saved for the next commit-fest: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Er, why saved? Until there's a new patch submission there's not going to be more work to do on this in the next fest. I think maybe you need to think a bit harder about the distinction between your TODO-items-in-waiting list and the commit fest queue. I was willing to wade through a pile of TODO-items-in-waiting this time, because I pressed you to make the list available before having sorted through it; but I'm not going to be pleased to see those same threads in the fest queue next time, unless someone's done some actual work in between. It is in the next fest so I will remember to ask if people have done any work on them --- if not they are either deleted or moved to the next commit fest. Are you suggesting we just delete the threads and let them die if they don't submit a new version? My understanding was that all items in a commit-fest have one of these three dispositions: . committed . rejected . referred back to author for more work We're really only interested in the third one here, and so, yes, the ball should be in the author's court, not yours. I don't see any reason for you to move items from one queue to another like that. It just looks like it's making work. 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] Headers dependencies cleanup
Zdenek Kotala wrote: Is it your assumption or do you mean some specific compiler? IIRC, inline is defined in C99 and my assumption :-) is that it should be supported by all compilers today. I try to look on buildmachine, There should be some useful configure output. My recollection is that we support C89, which might be a bit out of date, but then we try not to obsolete platforms if possible. 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] Expose checkpoint start/finish times into SQL.
Joshua D. Drake wrote: Theo Schlossnagle wrote: First whack at exposing the start and finish checkpoint times into SQL. Why is that useful? For knowing how long checkpoints are taking. If they are taking too long you may need to adjust your bgwriter settings, and it is a serious drag to parse postgresql logs for this info. Even if this were true, surely the answer is to improve the logging. Has this feature been discussed on -hackers? I don't recall it (and my memory has plenty of holes in it), but I'm sure that after attending my talk last Sunday Theo hasn't sent in a patch for an undiscussed feature ;-) 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] Expose checkpoint start/finish times into SQL.
Robert Treat wrote: On Thursday 03 April 2008 19:08, Andrew Dunstan wrote: Joshua D. Drake wrote: Theo Schlossnagle wrote: First whack at exposing the start and finish checkpoint times into SQL. Why is that useful? For knowing how long checkpoints are taking. If they are taking too long you may need to adjust your bgwriter settings, and it is a serious drag to parse postgresql logs for this info. Even if this were true, surely the answer is to improve the logging. Exposing everything into the log files isn't always sufficient (says the guy who maintains a remote admin tool) It should be now that you can have machine readable logs (says the guy who literally spent weeks making that happen) ;-) 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] Expose checkpoint start/finish times into SQL.
Joshua D. Drake wrote: Exposing everything into the log files isn't always sufficient (says the guy who maintains a remote admin tool) It should be now that you can have machine readable logs (says the guy who literally spent weeks making that happen) ;-) And how does the person get access to those? And what script do I need to write to make it happen? Don't get me wrong, the feature you worked entirely too hard on to get working is valuable but... being able to say, SELECT * FROM give_me_my_db_info; is much more useful in this context. How to load the CSV logs is very clearly documented. It's really *very* easy, so easy it's mostly CP. See http://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG If you are trying to tell me that that's too hard for a DBA, then I have to say you need better DBAs. In short, I should never have to go to log for this class of information. It should be available in the database. What you haven't explained is why this information needs to be kept in the db on a historical basis, as opposed to all the other possible diagnostics where history might be useful (and, as Tom has pointed out, this patch doesn keep it historically any way). I think there is quite possibly a good case for keeping some diagnostics in a table or tables, on a rolling basis, maybe. But then that's a facility that needs to be properly designed. 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] Expose checkpoint start/finish times into SQL.
Theo Schlossnagle wrote: Has this feature been discussed on -hackers? I don't recall it (and my memory has plenty of holes in it), but I'm sure that after attending my talk last Sunday Theo hasn't sent in a patch for an undiscussed feature ;-) Andrew: I don't think this feature has been discussed on hackers. The patch took about 15 minutes to author, so it sounds like the most concise way to start a conversation. Seems silly to start the conversation on hackers with a patch. :-) Well, not really. I believe -hackers has a much larger readership than -patches, so even for small features we generally want them discussed there. 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] actualized SQL/PSM patch
Jonah H. Harris wrote: On Tue, Apr 1, 2008 at 5:55 PM, Tom Lane [EMAIL PROTECTED] wrote: 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. We have a customer that wants to use it as part of a MySQL-to-Postgres migration. Using an implementation like this? I suspect anyone wanting to migrate their existing SQL/PSM stuff to Postgres will be less than impressed by our function body as a string mechanism. 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 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] Fwd: WIP: CASE statement for PL/pgSQL
Pavel Stehule wrote: correct queue Hello I finished this patch. Proposal: http://archives.postgresql.org/pgsql-hackers/2008-01/msg00696.php It's compatible with PL/SQL (Oracle) and SQL/PSM (ANSI). At the very least this patch is missing documentation and regression tests. 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] create language ... if not exists
Heikki Linnakangas wrote: Andreas 'ads' Scherbaum wrote: The attached patch for HEAD extends the CREATE LANGUAGE statement by an IF NOT EXISTS option which in effect changes the raised error into a notice. Before i continue working on this patch i would like to know if this extension has a chance to go into PG and what other changes i should apply (beside the missing documentation). The way we've solved this problem for other CREATE commands is to add OR REPLACE option, instead of IF NOT EXISTS. We should do the same here. My recollection is that we only do that where we need to for reasons of dependency. Not sure that applies here. 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] [HACKERS] Include Lists for Text Search
Simon Riggs wrote: As Greg mentions on another thread, not all patches are *intended* to be production quality by their authors. Many patches are shared for the purpose of eliciting general feedback. You yourself encourage a group development approach and specifically punish those people dropping completely finished code into the queue and expecting it to be committed as-is. If you post a patch that is not intended to be of production quality, it is best to mark it so explicitly. Then nobody can point fingers at you. Also, Bruce would then know not to put it in the queue of patches waiting for application. 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] [HACKERS] Include Lists for Text Search
Simon Riggs wrote: On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote: Simon Riggs wrote: As Greg mentions on another thread, not all patches are *intended* to be production quality by their authors. Many patches are shared for the purpose of eliciting general feedback. You yourself encourage a group development approach and specifically punish those people dropping completely finished code into the queue and expecting it to be committed as-is. If you post a patch that is not intended to be of production quality, it is best to mark it so explicitly. Then nobody can point fingers at you. Also, Bruce would then know not to put it in the queue of patches waiting for application. So it can be forgotten about entirely? H. I think if you post something marked Work In Progress, there is an implied commitment on your part to post something complete at a later stage. So if it's forgotten you would be the one doing the forgetting. ;-) 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] CopyReadLineText optimization
Heikki Linnakangas wrote: Andrew Dunstan wrote: Another question that occurred to me - did you try using strpbrk() to look for the next interesting character rather than your homegrown searcher gadget? If so, how did that perform? It looks like strpbrk() performs poorly: Yes, not surprising. I just looked at the implementation in glibc, which I assume you are using, and it seemed rather basic. The one in NetBSD's libc looks much more efficient. See http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/string/strpbrk.c?rev=1.1.2.1content-type=text/plaincvsroot=glibc and http://cvsweb.de.netbsd.org/cgi-bin/cvsweb.cgi/src/lib/libc/string/strpbrk.c?rev=1.16;content-type=text%2Fx-cvsweb-markup Not that what you've done isn't good, if a little obscure (as is the NetBSD implementation) 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] CopyReadLineText optimization
Heikki Linnakangas wrote: Andrew Dunstan wrote: I'm still a bit worried about applying it unless it gets some adaptive behaviour or something so that we don't cause any serious performance regressions in some cases. I'll try to come up with something. At the most conservative end, we could fall back to the current method on the first escape, quote or backslash character. Also, could we perhaps benefit from inlining some calls, or is your compiler doing that anyway? gcc does inline all static functions that are only called from one site, and small functions, using some heuristic. I don't think more aggressive inlining would help. Another question that occurred to me - did you try using strpbrk() to look for the next interesting character rather than your homegrown searcher gadget? If so, how did that perform? 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] CopyReadAttributesCSV optimization
Heikki Linnakangas wrote: Here's a patch to speed up CopyReadAttributesCSV. On the test case I've been playing with, loading the TPC-H partsupp table, about 20% CopyReadAttributesCSV (inlined into DoCopy, DoCopy itself is insignificant): [snip] The trick is to split the loop in CopyReadAttributesCSV into two parts, inside quotes, and outside quotes, saving some instructions in both parts. Your mileage may vary, but I'm quite happy with this. I haven't tested it much yet, but I wouldn't expect it to be a loss in any interesting scenario. The code also doesn't look much worse after the patch, perhaps even better. This looks sane enough, and worked for me in testing, so I'm going to apply it shortly. I'll probably add a comment or two about how the loops interact. 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] CopyReadLineText optimization
Heikki Linnakangas wrote: Heikki Linnakangas wrote: Heikki Linnakangas wrote: Attached is a patch that modifies CopyReadLineText so that it uses memchr to speed up the scan. The nice thing about memchr is that we can take advantage of any clever optimizations that might be in libc or compiler. Here's an updated version of the patch. The principle is the same, but the same optimization is now used for CSV input as well, and there's more comments. Another update attached: It occurred to me that the memchr approach is only safe for server encodings, where the non-first bytes of a multi-byte character always have the hi-bit set. We currently make the following assumption in the code: * These four characters, and the CSV escape and quote characters, are * assumed the same in frontend and backend encodings. * The four characters are the carriage return, line feed, backslash and dot. I think the requirement might well actually be somewhat stronger than that: i.e. that none of these will appear as a non-first byte in any multi-byte client encoding character. If that's right, then we should be able to write CopyReadLineText without bothering about multi-byte chars. If it's not right then I suspect we have some cases that can fail now anyway. (I believe some client encodings at least use backslash in subsequent chars, and that's a nasty one because the \. end sequence is hard coded). I believe all the chars up to 0x2f are safe - that includes both quote chars and dot) cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] CopyReadLineText optimization
Tom Lane wrote: BTW, I notice that the code allows CSV escape and quote characters that have the high bit set (in single-byte server encodings that is). Is this a good idea? It seems like such are extremely unlikely to be the same in two different encodings. Maybe we should restrict to the ASCII range? Especially if the client encoding is multibyte ... In the commonest case these are both either or '. I would not have any objection to requiring them to be ASCII chars. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] CopyReadLineText optimization
Heikki Linnakangas wrote: Andrew Dunstan wrote: Heikki Linnakangas wrote: Another update attached: It occurred to me that the memchr approach is only safe for server encodings, where the non-first bytes of a multi-byte character always have the hi-bit set. We currently make the following assumption in the code: * These four characters, and the CSV escape and quote characters, are * assumed the same in frontend and backend encodings. * The four characters are the carriage return, line feed, backslash and dot. I think the requirement might well actually be somewhat stronger than that: i.e. that none of these will appear as a non-first byte in any multi-byte client encoding character. If that's right, then we should be able to write CopyReadLineText without bothering about multi-byte chars. If it's not right then I suspect we have some cases that can fail now anyway. No, we don't require that, and we do handle it correctly. We use pg_encoding_mblen to determine the length of each character in CopyReadLineText when the encoding is a client-only encoding, and only look at the first byte of each character. In CopyReadAttributesText, where we have a similar loop, we've already transformed the input to server encoding. Oops. I see that now. Funny how I missed it when I went looking for it :-( I think I understand the patch now :-) I'm still a bit worried about applying it unless it gets some adaptive behaviour or something so that we don't cause any serious performance regressions in some cases. Also, could we perhaps benefit from inlining some calls, or is your compiler doing that anyway? cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] CopyReadLineText optimization
Heikki Linnakangas wrote: Andrew Dunstan wrote: I'm still a bit worried about applying it unless it gets some adaptive behaviour or something so that we don't cause any serious performance regressions in some cases. I'll try to come up with something. At the most conservative end, we could fall back to the current method on the first escape, quote or backslash character. That's far too conservative, I think. Somewhere a bit short of your observed breakeven point seems about right. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] CopyReadLineText optimization
Greg Smith wrote: On Thu, 6 Mar 2008, Heikki Linnakangas wrote: At the most conservative end, we could fall back to the current method on the first escape, quote or backslash character. I would just count the number of escaped/quote characters on each line, and then at the end of the line switch modes between the current code on the new version based on what the previous line looked like. That way the only additional overhead is a small bit only when escapes show up often, plus a touch more just once per line. Barely noticable in the case where nothing is escaped, very small regression for escape-heavy stuff but certainly better than the drop you reported in the last rev of this patch. Rev two of that design would keep a weighted moving average of the total number of escaped characters per line (say wma=(7*wma+current)/8) and switch modes based on that instead of the previous one. There's enough play in the transition between where the two approaches work better at that this should be easy enough to get a decent transition between. Based on your data I would put the transition at wma4, which should keep the old code in play even if only half the lines have the bad regression that shows up with 8 escapes per line. I'd be inclined just to look at the first buffer of data we read in, and make a one-off decision there, if we can get away with it. Then the cost of testing is fixed rather than per line. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] WIP: guc enums
Tom Lane wrote: Having to have two extra hook functions for every variable seems like a lot of notational overhead for not much gain. +1 cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] CopyReadLineText optimization
Heikki Linnakangas wrote: So the overhead of using memchr slows us down if there's a lot of escape or quote characters. The breakeven point seems to be about 1 in 8 characters. I'm not sure if that's a good tradeoff or not... How about we test the first buffer read in from the file and change strategy accordingly? cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] NetBSD/MIPS supports dlopen
Alvaro Herrera wrote: Both done -- I backpatched all the way down to 7.4 (and later I noticed that the only 7.3 BF members are NetBSD). Haven't we declared 7.3 at EOL anyway? cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] NetBSD/MIPS supports dlopen
Alvaro Herrera wrote: Andrew Dunstan wrote: Alvaro Herrera wrote: Both done -- I backpatched all the way down to 7.4 (and later I noticed that the only 7.3 BF members are NetBSD). Haven't we declared 7.3 at EOL anyway? That's why I didn't backpatch it there. But if that's the case, why are we still reporting 7.3 in the buildfarm status page? Because until a couple of weeks ago those two machines were still reporting that branch. When they are 30 days old the reports will drop off the page. (It looks like salamander has stopped altogether, which Tom mentioned the other day would distress him some.) cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] [BUGS] BUG #4007: chr(0) doesn't work anymore
Bruce Momjian wrote: Tom Lane wrote: Steve Clark [EMAIL PROTECTED] writes: I'm not sure I understand what you mean about TEXT being null-safe. What are the issues, and why was it supported for years and now abruptly changed. It never was supported, we are simply plugging a hole that let you create a text value that would be likely to malfunction in subsequent use. Seems we never documented that chr(0) is not supported. I have applied the following doc patch to CVS HEAD and 8.3.X. The NULL (0) character is not allowed because text data types cannot reliably store such bytes. Reliably is arguably misleading here. cheers andrew -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Re: [PATCHES] Fix for initdb failures on Vista
Dave Page wrote: The attached patch fixes problems reported primarily on Vista, but also on some Windows 2003 and XP installations in which initdb reports that it cannot find postgres.exe. This occurs because of security-related changes implemented in Windows Vista and recent patches on older OS's. When running initdb or pg_ctl we currently create a restricted security token with the Administrators and Power Users groups (and thus their privileges) removed and re-execute the same program using the restricted token. This ensures that the process is run without potentially dangerous privileges no matter what user account it was started from. On Vista and friends however, the default DACL (list of Access Control Entries) used in the restricted token contains Administrators (the group) System when we run as Administrator, vs. User + System when run as other users. Because we then drop Administrators, we are left with only the System ACE in the DACL, which does not allow us to use CreatePipe()/CreateProcess(). To fix this, when we create the restricted process, we initially start it in suspended mode. We modify it's DACL to explicitly add an ACE for the current user, and then resume the child process. This remains secure because administrative privileges are granted to the groups that we've dropped, not the user itself. I've tested on Vista and XP, but additional testing would be useful (Andrew, Magnus?). Please apply to head, 8.3 and 8.2 This appears to work for initdb. But make check fails after the initdb stage, I think because pg_regress doesn't use pg_ctl to start the postmaster. The log just reads Access is denied' I don't have too much difficulty with that as long as we stipulate that postgres has to be built, or at least checked, as a non-privileged user (c.f. recent discussion of building RPMs as root). Alternatively, we should also patch pg_regress.c cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Fix for initdb failures on Vista
Magnus Hagander wrote: I've tested on Vista and XP, but additional testing would be useful (Andrew, Magnus?). Please apply to head, 8.3 and 8.2 Other than Heikkis comments: We obviously need to test-build on mingw, so if someone can do that, pleae do. If not, I'll try to get my VM up and running on it (since mingw doesn't work on my win64 box). I'll look at testing mingw on my 32bit Vista box. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Fix pgstatindex using for large indexes
Tom Lane wrote: Is there any currently supported platform which does not have uint64? I don't know, and neither do you. Maybe we should look at some reasonable way of getting the info out of a compiled instance. How about if we get pg_config to output the value of INT64_IS_BUSTED? Then we could add a step to the buildfarm client to catch all the output from pg_config. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] fix in --help output
Zdenek Kotala wrote: Tom Lane napsal(a): Zdenek Kotala [EMAIL PROTECTED] writes: I attach fix for --help output. I replaced --NAME... with -NAME and add some example. getopt parse -- as a end of options and rest of line is not parsed. Surely this is outright wrong. Or if you do have a getopt that acts that way, the bug is that we are using it rather than one that acts the way we want. Ah, sorry it really does not work. However, I get following error on Solaris: bash-3.2$ /usr/postgres/8.2/bin/postgres -D /tmp/db --share_buffers=16000 /usr/postgres/8.2/bin/postgres: illegal option -- share_buffers=16000 Try postgres --help for more information. but following command works fine: /usr/postgres/8.2/bin/postgres -D /tmp/db -c shared_buffers=16000 By my opinion problem is in getopt which interprets -- as a end of options list. See http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02 Guideline 10 It maybe work on linux but I think it is not portable solution. -- on its own might indicate the end of arguments, but that's quite different from --foo=bar. Guideline 10 of the above surely only refers to -- as an entire argument, not to -- as the first two characters of an argument. If your getopt treats *any* -- as the end of options then I think it is broken (complain to your vendor ;-) ). And the answer is known - use the one we have in src/port. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] WIP: plpgsql source code obfuscation
Peter Eisentraut wrote: Am Montag, 28. Januar 2008 schrieb Pavel Stehule: this patch define new function flag - OBFUSCATE. With this flag encrypted source code is stored to probin column. Password is stored in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server does (where privileged users can access system tables with source code or can use debugger). Have you thought about a solution that applies the regular access privileges to pg_proc in order to hide some content from less privileged users? This question is a good one, especially since we have waiting in the wings the work my SOC student did a few months ago on column level privileges. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] WIP: plpgsql source code obfuscation
Pavel Stehule wrote: Hello this patch define new function flag - OBFUSCATE. With this flag encrypted source code is stored to probin column. Password is stored in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server does (where privileged users can access system tables with source code or can use debugger) ToDo: Dump Maybe a better TODO would be to do this task in the way that has previously been suggested: http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php I'm certainly not happy about any proposal to put a password/key in a GUC var - that strikes me as a major footgun. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] WIP: plpgsql source code obfuscation
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Maybe a better TODO would be to do this task in the way that has previously been suggested: http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php I'm certainly not happy about any proposal to put a password/key in a GUC var - that strikes me as a major footgun. We didn't really have a better solution to the key management problem, though, did we? At least I don't see anything about it in that thread. Yeah. Maybe we could have the GUC var contain the name of a key file rather than the key itself. If we require that the name be relative to the datadir that might be tolerably secure. However, I definitely agree that a separate loadable PL is the way to go for functionality of this sort. There is no way that a dependency on pgcrypto is going to be accepted into core, not even in the (ahem) obfuscated way that it's presented here. If we do anything in core it could be to make provision for an obfuscation/encryption hook via a loadable module. Various interesting encoding issues could arise with dumping and restoring transformed program text - I haven't thought that through yet. But I agree a simple PL wrapper makes sense to start with, at any rate. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] WIP: plpgsql source code obfuscation
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: However, I definitely agree that a separate loadable PL is the way to go for functionality of this sort. There is no way that a dependency on pgcrypto is going to be accepted into core, not even in the (ahem) obfuscated way that it's presented here. If we do anything in core it could be to make provision for an obfuscation/encryption hook via a loadable module. My recollection is that certain cryptography laws make hooks for crypto just as problematic as actual crypto code. We'd have to tread very carefully --- general purpose hooks are OK but anything narrowly tailored to encryption purposes would be a hazard. This is one reason that I'd prefer to see it as an external PL rather than embedded in core. It could be something other than encryption; any sort of transformation might fit. For example, one might do something like: gzip | some-sort-of-shuffle | base64-encode as a sort or poor man's obfuscation Various interesting encoding issues could arise with dumping and restoring transformed program text - I haven't thought that through yet. I think we have already solved that with md5 passwords, and could easily reuse the same kind of approach. You just base64 encode the crypted text (or whatever you need to do to avoid funny characters in it), and make sure that there's some way to distinguish already-crypted from not-already-crypted function bodies. I don't see how a binary MD5 checksum has any encoding component. But using this example, it seems to me that if we dump the encrypted/encoded source and restore into another database with a different encoding, the decoded/decrypted source will still be in the old database encoding, i.e. not valid in the new database encoding. We've just gone around closing doors like this. You might be able to fix it by storing the database encoding name along with the encrypted/encoded source, so it could be transformed at the other end. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: How does that prevent spoofing? It creates a lock file that is the same name as the socket file that a default-configured client would use, so it prevents a spoofed socket from being created. Only if the attacker didn't get there first. I think this idea is nothing but a crude kluge anyway... I agree. I remain of the opinion that this is not a problem than can be solved purely within the bounds of postgres. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Alvaro Herrera wrote: Andrew Dunstan wrote: I agree. I remain of the opinion that this is not a problem than can be solved purely within the bounds of postgres. I agree. Please comment on my proposed solution. I'm not sure tmp cleaners will work that well against a determined spoofer. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Alvaro Herrera wrote: Andrew Dunstan wrote: Alvaro Herrera wrote: Andrew Dunstan wrote: I agree. I remain of the opinion that this is not a problem than can be solved purely within the bounds of postgres. I agree. Please comment on my proposed solution. I'm not sure tmp cleaners will work that well against a determined spoofer. I don't understand. The tmp cleaner is something we have to _avoid_. Let me repeat my proposal. I propose to create a dangling symlink on system startup in /tmp/.s.PGSQL.port to the real socket, which is not on a world-writable directory. This avoids the spoofer, because he cannot create the socket -- the symlink is occupying its place. The only problem with this proposal is that the tmp cleaner would remove the symlink. The solution to this is to configure the tmp cleaner so that it doesn't do that. It absolutely requires cooperation from the sysadmin, both to setup the symlink initially, and to configure the tmp cleaner. Oh. I'm sorry. Yes, I think this would work. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Unworkable column delimiter characters for COPY
Tom Lane wrote: I see that we disallow the CSV quote character from appearing in the null_print string, but not the escape character. Is this correct/sensible? Yes, because: . nulls are never quoted . fields containing the quote char must be quoted . the escape char is only magical inside quoted fields If it is correct, maybe the delimiter could also match the escape character? Yes, probably. Crazy, but I think it's workable. I'll take that test out, and just make sure that the delimiter is different from the quote. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Unworkable column delimiter characters for COPY
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think at minimum we need to forbid b, f, n, r, t, v, which are the
control character representations currently recognized by COPY.
But I'm tempted to make it reject all 26 lower-case ASCII letters,
as a form of future-proofing. Thoughts?
Assuming this is only for non-CSV mode, it seems OK.
On looking closer, 'x', octal digits, and '.' would also be trouble.
So I made it reject a-z, 0-9, and dot.
It appears that the CSV mode is a few bricks shy of a load here as
well: it will let you do CSV DELIMITER '' resulting in entirely
broken output. It seems we ought to forbid delimiter from matching CSV
quote or escape characters. I'll let you clean up that case though...
This should do the trick - I'll apply it tomorrow.
cheers
andrew
Index: copy.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/copy.c,v
retrieving revision 1.293
diff -c -r1.293 copy.c
*** copy.c 27 Dec 2007 18:28:58 - 1.293
--- copy.c 28 Dec 2007 04:07:06 -
***
*** 889,894
--- 889,907
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(COPY delimiter cannot be
\%s\, cstate-delim)));
+ /* In CSV mode, disallow quote or escape chars as delimiter */
+ if (cstate-csv_mode)
+ {
+ if (cstate-delim[0] == cstate-quote[0])
+ ereport(ERROR,
+
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+errmsg(COPY delimiter and
quote must be different)));
+ else if (cstate-delim[0] == cstate-escape[0])
+ ereport(ERROR,
+
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+errmsg(COPY delimiter and
escape must be different)));
+ }
+
/* Check header */
if (!cstate-csv_mode cstate-header_line)
ereport(ERROR,
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [PATCHES] Doc-patch: PAM authentication fails for local UNIX users
Magnus Hagander wrote: On Tue, Dec 18, 2007 at 12:41:56PM +0530, Dhanaraj M wrote: Hi all, This is the continuation to the discussion that we had in the hacker's list. http://archives.postgresql.org/pgsql-hackers/2007-08/msg00684.php Here, I like to add some details in 20.2.6. PAM authentication section. http://www.postgresql.org/docs/8.2/interactive/auth-methods.html#AUTH-PAM Can someone review and make changes, if required? Thanks. Eh, those extensions are only valid if you use PAM with a shadow password file, no? You shouldn't need root if you use say PAM-with-LDAP? Also, it strikes me that granting the postgres user read access to the shadow file is probably very poor security practice, and not something I would want to recommend without considerable thought. What we should say, rather, is that PAM auth is likely to fail if your PAM is set up to use the shadow file rather than an auth source such as LDAP which does not require privileged file access. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)
Gokulakannan Somasundaram wrote: I would suggest forgetting that part and submitting the part that has some chance of getting accepted. Actually i want to submit the patch, which is best according to me. That's not an attitude that is likely to succeed - you need to take suggestions from Tom very seriously. Also, please submit patches as context diffs, as set out in the Developer FAQ, which you should probably read carefully: http://www.postgresql.org/docs/faqs.FAQ_DEV.html cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] buildenv.pl/buildenv.bat
Magnus Hagander wrote: Well, I honestly think we can live with it for one cycle. As soon as 8.4 opens I'll get to work converting these .bat files to pure one line wrappers. Ok. We obviously don't agree on what to do here, so let's open it up for somebody else to comment on what they think is best. My take is document the fact that you have to do it twice. Andrews is this patch. Nobody else seems to care :-) My reasoning is that I don't want to make people change their setups in future. The should just be able to set up buildenv.pl now and continue to use it even when I've fixed the .bat files next release. Writing and calling a temp .bat file might be yucky - having to keep two environment files is a lot more yucky, IMNSHO, and we shouldn't make people do it. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] buildenv.pl/buildenv.bat
Magnus Hagander wrote: On Fri, Dec 14, 2007 at 03:39:14PM +, Dave Page wrote: Andrew Dunstan wrote: Writing and calling a temp .bat file might be yucky - having to keep two environment files is a lot more yucky, IMNSHO, and we shouldn't make people do it. +1 Ok, I guess I'm outvoted ;-) I don't care *that* much about it, so let's do it your way. You need help testing that patch further, or do you consider it ready for application? If so, go. Yes, please do test it - I don't use buildenv.* at all normally, as then buildfarm client takes care of its own environment, and that's what I usually use to build on Windows. cheers andrew. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) wrote: Anybody think this is good, bad, or silly? Does the issue need explicit documentation, and if so where and how? I'm going to have to vote 'silly' on this one. While I agree that in general we should discourage, and not provide explicit command-line options for, passing a password on the command-line, I don't feel that it makes sense to explicitly complicate things to prevent it. It's a matter of being consistent. If we think such a facility shouldn't be provided on security grounds, then we shouldn't allow it via a backdoor, ISTM. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] buildenv.pl/buildenv.bat
Magnus Hagander wrote:
You seem to have misunderstood what I am suggesting. Of course we should
document use of buildenv.pl in addition to the hacky fix to the .bat
files. The hack is the part that would be invisible. The docs would be
visible and contain what would be our ongoing practice.
Correct, I was misunderstanding it :-)
I still can't say I like that hack though. I'd rather document that you
have to do it in the .bat file for docs + gui build.
But it's better than what I thought you were proposing :-)
Well, I honestly think we can live with it for one cycle. As soon as 8.4
opens I'll get to work converting these .bat files to pure one line
wrappers.
Meanwhile, here's the proposed patch. If you want something else you'll
have to do it.
I don't know how many people regularly build on Windows other than you,
me and Dave.
cheers
andrew
Index: doc/src/sgml/install-win32.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/install-win32.sgml,v
retrieving revision 1.42
diff -c -r1.42 install-win32.sgml
*** doc/src/sgml/install-win32.sgml 28 Nov 2007 15:42:31 - 1.42
--- doc/src/sgml/install-win32.sgml 9 Dec 2007 19:31:36 -
***
*** 58,69
Before you build, edit the file filenameconfig.pl/filename to reflect the
configuration options you want set, including the paths to libraries used.
If you need to set any other environment variables, create a file called
! filenamebuildenv.bat/filename and put the required commands there. For
example, to add the path for bison when it's not in the PATH, create a file
containing:
screen
!@ECHO OFF
!SET PATH=%PATH%;c:\some\where\bison\bin
/screen
/para
--- 58,68
Before you build, edit the file filenameconfig.pl/filename to reflect the
configuration options you want set, including the paths to libraries used.
If you need to set any other environment variables, create a file called
! filenamebuildenv.pl/filename and put the required commands there. For
example, to add the path for bison when it's not in the PATH, create a file
containing:
screen
!$ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
/screen
/para
***
*** 209,218
/userinput
/screen
To change the default build configuration to debug, put the following
!in the filenamebuildenv.bat/filename file:
screen
userinput
! set CONFIG=Debug
/userinput
/screen
/para
--- 208,217
/userinput
/screen
To change the default build configuration to debug, put the following
!in the filenamebuildenv.pl/filename file:
screen
userinput
! $ENV{CONFIG}=Debug;
/userinput
/screen
/para
***
*** 263,269
required parts first. Also, make sure that the DLLs required to load all
parts of the system (such as the Perl and Python DLLs for the procedural
languages) are present in the system path. If they are not, set it through
!the filenamebuildenv.bat/filename file. To run the tests, run one of
the following commands from the filenamesrc\tools\msvc/filename
directory:
screen
--- 262,268
required parts first. Also, make sure that the DLLs required to load all
parts of the system (such as the Perl and Python DLLs for the procedural
languages) are present in the system path. If they are not, set it through
!the filenamebuildenv.pl/filename file. To run the tests, run one of
the following commands from the filenamesrc\tools\msvc/filename
directory:
screen
***
*** 339,349
/para/listitem
/varlistentry
/variablelist
!Edit the filenamebuildenv.bat/filename file, and add a variable for the
location of the root directory, for example:
screen
! @ECHO OFF
! SET DOCROOT=c:\docbook
/screen
To build the documentation, run the command
filenamebuilddoc.bat/filename. Note that this will actually run the
--- 338,347
/para/listitem
/varlistentry
/variablelist
!Edit the filenamebuildenv.pl/filename file, and add a variable for the
location of the root directory, for example:
screen
! $ENV{DOCROOT}='c:\docbook';
/screen
To build the documentation, run the command
filenamebuilddoc.bat/filename. Note that this will actually run the
Index: src/tools/msvc/builddoc.bat
===
RCS file: /cvsroot/pgsql/src/tools/msvc/builddoc.bat,v
retrieving revision 1.5
diff -c -r1.5 builddoc.bat
*** src/tools/msvc/builddoc.bat 17 Mar 2007 14:01:01 - 1.5
--- src/tools/msvc/builddoc.bat 9 Dec 2007 19:31:36 -
***
*** 1,5
@echo off
! REM Adjust path for your docbook installation in buildenv.bat
REM $PostgreSQL: pgsql/src/tools/msvc/builddoc.bat,v 1.5 2007/03/17
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Tom Lane wrote: I wrote: I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. As best I can tell at the moment, I have not tested 5.6.1 with anything later than our 7.2 branch, so I don't know exactly where the breakage slipped in. It may be of long standing. Actually, libperl seems to dump core in the same place in every PG version, back to and including 7.2, so what seems more likely is that this copy of perl is just plain broken. Since we didn't have any form of regression test for plperl back then, it's entirely possible that I never tested any further than compiling plperl with that setup. So we still need someone to try it with a good copy of 5.6 ... OK, I have built a fresh copy of perl 5.6.2 and built and linked HEAD against it. It passes the regression tests and the UTF8 test, and doesn't dump core. This is on FC6/x86_64. cheers andrew ---(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
[PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
I wrote:
OK, I have a fairly ugly manual workaround, that I don't yet
understand, but seems to work for me.
In your session, run the following code before you do anything else:
CREATE OR REPLACE FUNCTION test(text) RETURNS bool LANGUAGE plperl as $$
return shift =~ /\xa9/i ? 'true' : 'false';
$$;
SELECT test('a');
DROP FUNCTION test(text);
After that we seem to be good to go with any old UTF8 chars.
I'm looking at automating this so the workaround can be hidden, but
I'd rather understand it first.
(Core guys: If we can hold RC1 for a bit while I get this fixed that
would be good.)
The attached patch works for me to eliminate the errors. Please test
ASAP.
Given our time constraints I intend to apply this to HEAD and backpatch
it to 8.2 and 8.1, unless there's a strenuous objection. That will give
us some buildfarm coverage on it, although we don't seem to have any
perl 5.6.x on the buildfarm that I could see. We've had a positive test
report, no negative reports, and I'm fairly sure the patch is at worst
harmless.
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: +* Fill in just enough information to set up this perl +* function in the safe container and call it. +* For some reason not entirely clear, it prevents errors that +* can arise from the regex code later trying to load +* utf8 modules. How many versions of Perl have you tried this against? Only one :-( I don't have a farm of perl versions hanging round. That's one of the reasons I asked that people test it. The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I spent an hour wrestling unsuccessfully with it this morning but I don't have more time to spend on it. Systems older than 5.6 don't matter, as we don't do any UTF8 mangling on those. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [DOCS] Partition: use triggers instead of rules
Joshua D. Drake wrote: A trigger will probably beat a rule for inserts/updates involving a small number of rows. Which is exactly what partitioning is doing. For large numbers of rows, like an INSERT/SELECT from another large table, the rule is likely to win, because its overhead is paid once per query not once per row. Also, if you implement the trigger with an EXECUTE (forcing a planning cycle) intead of hard-coded commands, the speed advantage becomes even more dubious. Not for partitioning. Although I agree with your sentiments for normal operation. Joshua, you're not making much sense here. Tom is talking about partitioning and his analysis is correct *in the partitioning case* AFAICS. What basis do you have for saying he is not? cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Greg Sabino Mullane wrote:
Just as a followup, I reported this as a bug and it is being looked
at and discussed:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=47576
Appears there is no easy resolution yet.
We might be able to do something with the suggested workaround. I
will see what I can do, unless you have already tried.
OK, I have a fairly ugly manual workaround, that I don't yet
understand, but seems to work for me.
In your session, run the following code before you do anything else:
CREATE OR REPLACE FUNCTION test(text) RETURNS bool LANGUAGE plperl as $$
return shift =~ /\xa9/i ? 'true' : 'false';
$$;
SELECT test('a');
DROP FUNCTION test(text);
After that we seem to be good to go with any old UTF8 chars.
I'm looking at automating this so the workaround can be hidden, but
I'd rather understand it first.
(Core guys: If we can hold RC1 for a bit while I get this fixed that
would be good.)
The attached patch works for me to eliminate the errors. Please test ASAP.
cheers
andrew
Index: src/pl/plperl/plperl.c
===
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.132
diff -c -r1.132 plperl.c
*** src/pl/plperl/plperl.c 15 Nov 2007 22:25:17 - 1.132
--- src/pl/plperl/plperl.c 29 Nov 2007 05:32:22 -
***
*** 149,154
--- 149,156
static SV *newSVstring(const char *str);
static SV **hv_store_string(HV *hv, const char *key, SV *val);
static SV **hv_fetch_string(HV *hv, const char *key);
+ static SV *plperl_create_sub(char *proname, char *s, bool trusted);
+ static SV *plperl_call_perl_func(plperl_proc_desc *desc, FunctionCallInfo fcinfo);
/*
* This routine is a crock, and so is everyplace that calls it. The problem
***
*** 504,509
--- 506,558
else
{
eval_pv(SAFE_OK, FALSE);
+ if (GetDatabaseEncoding() == PG_UTF8)
+ {
+
+ /*
+ * Fill in just enough information to set up this perl
+ * function in the safe container and call it.
+ * For some reason not entirely clear, it prevents errors that
+ * can arise from the regex code later trying to load
+ * utf8 modules.
+ */
+
+ plperl_proc_desc desc;
+ FunctionCallInfoData fcinfo;
+ FmgrInfo outfunc;
+ HeapTuple typeTup;
+ Form_pg_type typeStruct;
+ SV *ret;
+ SV *func;
+
+ /* make sure we don't call ourselves recursively */
+ plperl_safe_init_done = true;
+
+ /* compile the function */
+ func = plperl_create_sub(
+ utf8fix,
+ return shift =~ /\\xa9/i ? 'true' : 'false' ;,
+ true);
+
+
+ /* set up to call the function with a single text argument 'a' */
+ desc.reference = func;
+ desc.nargs = 1;
+ desc.arg_is_rowtype[0] = false;
+ fcinfo.argnull[0] = false;
+ fcinfo.arg[0] =
+ DatumGetTextP(DirectFunctionCall1(textin,
+ CStringGetDatum(a)));
+ typeTup = SearchSysCache(TYPEOID,
+ TEXTOID,
+ 0, 0, 0);
+ typeStruct = (Form_pg_type) GETSTRUCT(typeTup);
+ fmgr_info(typeStruct-typoutput,(desc.arg_out_func[0]));
+ ReleaseSysCache(typeTup);
+
+ /* and make the call */
+ ret = plperl_call_perl_func(desc,fcinfo);
+ }
}
plperl_safe_init_done = true;
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] fulltext parser strange behave
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I've just been looking at the state machine in wparser_def.c. I
think the processing for entities is also a few bob short in the
pound. It recognises decimal numeric character references, but nor
hexadecimal numeric character references. That's fairly silly since
the HTML spec specifically says the latter are particularly
useful. The rules for named entities are also deficient w.r.t.
digits, just like the case of tags that Tom noticed. This isn't
academic: HTML features a number of named entities with digits in
the name (sup2, frac14 for example).
In XML at least, legal names are defined by the following rules from
the spec:
...
[A-Za-z:_][A-Za-z0-9:_.-]*
I suggest we use that or something very close to it as the rule for
names in these patterns.
No objections here. Who wants to patch wparser_def?
I can get to it some time in the next week. - rather snowed under
right now.
BTW, I'm also suspicious of the clause that allows ?xml ... it
appears that it will allow ?xfoo and ?XFOO also, which seems quite
odd, especially the latter.
Here's a patch that fixes the patterns for numeric entities, tag names,
and removes the upper case 'X' case in the special case for an XML
prolog. There are still some oddities, but I decided against making
heroic efforts to fix them. It's probably less important if the patterns
are slightly too liberal (e.g. accepting a href=qweqwe ) than if
they don't recognize what they are alleged to recognize.
cheers
andrew
Index: doc/src/sgml/textsearch.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/textsearch.sgml,v
retrieving revision 1.36
diff -c -r1.36 textsearch.sgml
*** doc/src/sgml/textsearch.sgml 16 Nov 2007 03:23:07 - 1.36
--- doc/src/sgml/textsearch.sgml 19 Nov 2007 13:22:11 -
***
*** 1862,1873
/row
row
entryliteraltag//entry
! entryHTML tag/entry
entryliterallt;A HREF=dictionaries.htmlgt;/literal/entry
/row
row
entryliteralentity//entry
! entryHTML entity/entry
entryliteralamp;amp;/literal/entry
/row
row
--- 1862,1873
/row
row
entryliteraltag//entry
! entryHTML-type tag/entry
entryliterallt;A HREF=dictionaries.htmlgt;/literal/entry
/row
row
entryliteralentity//entry
! entryHTML-type entity/entry
entryliteralamp;amp;/literal/entry
/row
row
Index: src/backend/tsearch/wparser_def.c
===
RCS file: /cvsroot/pgsql/src/backend/tsearch/wparser_def.c,v
retrieving revision 1.10
diff -c -r1.10 wparser_def.c
*** src/backend/tsearch/wparser_def.c 15 Nov 2007 22:25:16 - 1.10
--- src/backend/tsearch/wparser_def.c 19 Nov 2007 13:22:11 -
***
*** 95,101
Hyphenated word part, all letters,
Hyphenated word part, all ASCII,
Space symbols,
! HTML tag,
Protocol head,
Hyphenated word, letters and digits,
Hyphenated word, all ASCII,
--- 95,101
Hyphenated word part, all letters,
Hyphenated word part, all ASCII,
Space symbols,
! HTML-type tag,
Protocol head,
Hyphenated word, letters and digits,
Hyphenated word, all ASCII,
***
*** 105,111
Decimal notation,
Signed integer,
Unsigned integer,
! HTML entity
};
--- 105,111
Decimal notation,
Signed integer,
Unsigned integer,
! HTML-type entity
};
***
*** 136,141
--- 136,143
TPS_InHTMLEntity,
TPS_InHTMLEntityNumFirst,
TPS_InHTMLEntityNum,
+ TPS_InHTMLEntityHexNumFirst,
+ TPS_InHTMLEntityHexNum,
TPS_InHTMLEntityEnd,
TPS_InTagFirst,
TPS_InXMLBegin,
***
*** 815,836
{p_isEOF, 0, A_POP, TPS_Null, 0, NULL},
{p_iseqC, '#', A_NEXT, TPS_InHTMLEntityNumFirst, 0, NULL},
{p_isasclet, 0, A_NEXT, TPS_InHTMLEntity, 0, NULL},
{NULL, 0, A_POP, TPS_Null, 0, NULL}
};
static const TParserStateActionItem actionTPS_InHTMLEntity[] = {
{p_isEOF, 0, A_POP, TPS_Null, 0, NULL},
! {p_isasclet, 0, A_NEXT, TPS_InHTMLEntity, 0, NULL},
{p_iseqC, ';', A_NEXT, TPS_InHTMLEntityEnd, 0, NULL},
{NULL, 0, A_POP, TPS_Null, 0, NULL}
};
static const TParserStateActionItem actionTPS_InHTMLEntityNumFirst[] = {
{p_isEOF, 0, A_POP, TPS_Null, 0, NULL},
{p_isdigit, 0, A_NEXT, TPS_InHTMLEntityNum, 0, NULL},
{NULL, 0, A_POP, TPS_Null, 0, NULL}
};
static const TParserStateActionItem actionTPS_InHTMLEntityNum[] = {
{p_isEOF, 0, A_POP, TPS_Null, 0, NULL},
{p_isdigit, 0, A_NEXT, TPS_InHTMLEntityNum, 0, NULL},
--- 817,852
{p_isEOF, 0, A_POP, TPS_Null, 0, NULL},
{p_iseqC, '#', A_NEXT, TPS_InHTMLEntityNumFirst, 0, NULL},
{p_isasclet, 0, A_NEXT, TPS_InHTMLEntity, 0, NULL},
+ {p_iseqC
Re: [PATCHES] [HACKERS] fulltext parser strange behave
Tom Lane wrote: I don't approve of the changes to the exposed token type names, but the state machine changes seem sane first-glance. Well, I think it's just plain wrong to describe as HTML tags and entities things that just aren't. In any case, what I changed was not the name (or alias, to be more precise), but the exposed description. The aliases (tag, entity) would remain the same. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] fulltext parser strange behave
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I don't approve of the changes to the exposed token type names, but the state machine changes seem sane first-glance. Well, I think it's just plain wrong to describe as HTML tags and entities things that just aren't. Maybe, but HTML-type is an unhelpful description. Isn't there a more general markup standard that subsumes both HTML and XML? (I seem to recall that SGML might be that, but not sure.) Most people haven't heard of SGML. I'd settle for XML tag or maybe XML/HTML tag. Any other bids? cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] fulltext parser strange behave
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Am Montag, 19. November 2007 schrieb Tom Lane: Maybe, but HTML-type is an unhelpful description. Isn't there a more general markup standard that subsumes both HTML and XML? (I seem to recall that SGML might be that, but not sure.) I think XML tag would actually cover anything that would be valid as an HTML tag. +1 for XML tag, then. Changed to XML tag and XML entity. Code names adjusted accordingly. Committed. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Contrib docs v1
Tom Lane wrote: Albert Cervera i Areny [EMAIL PROTECTED] writes: [ contrib sgml docs ] I am distressed to discover that these seem to have been generated from a snapshot taken some time in June, as they are missing the last five months' worth of changes to the now-deleted README files. I guess that's why we have an Attic, no? They aren't really deleted. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Unclarity of configure options
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support This turns the message from something merely a tad unclear into an outright lie. --with-libxslt does not cause contrib/xml2 (or any other part of contrib) to get built. Better would be --with-libxslt build with XSLT (affects only contrib/xml2) What is more, if we're going to do this we should mark *all* the options that only affect contrib, which is why I objected to doing this on its own in the first place. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Unclarity of configure options
Bruce Momjian wrote: Andrew Dunstan wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support This turns the message from something merely a tad unclear into an outright lie. --with-libxslt does not cause contrib/xml2 (or any other part of contrib) to get built. Better would be --with-libxslt build with XSLT (affects only contrib/xml2) What is more, if we're going to do this we should mark *all* the options that only affect contrib, which is why I objected to doing this on its own in the first place. Uh, what other configure options to we have that only affect /contrib? --with-ossp-uuid at least, IIRC This was discussed previously, BTW. Maybe you haven't read all the mail. Note that cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] V0.1 patch for TODO Item: SQL-language reference parameters by name.
Gevik Babakhani wrote: Hello all, Hereby an alpha version regarding the: TODO Item: SQL-language reference parameters by name. I am sending this patch to check if I am on the right track. So please take a look at this if possible. Step 1: don't use c++ style comments like this: + //TODO: Check here C89 is basically our standard. gcc -std=c89 will check that it complies. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Preliminary patch for tsearch example dictionaries/parsers in contrib
Sergey V. Karpov wrote: Built-in regex engine seems to not support the one feature critical to the dict_regex operation - it is not able to report the partial match in a case when the matching fails solely due to premature end of input string (i.e. when matching may possibly succeed after adding some data to the string). If it is possible to achieve this behaviour with built-in engine, please point me to the right direction. Adding new code at this stage of the process is bad enough. Adding new code which adds a library dependency we have not previously had at this stage of the process is quite unacceptable IMNSHO, and I will protest very loudly about it. Quite apart from anything else it will almost certainly break many buildfarm members. Are we in beta or not? To me, beta means nothing but bug fixes go in, period. No ifs, no buts, no maybes, no exceptions. And that should definitely go for contrib as well. We need a bit of self-discipline around here. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] ecpg thread-safe descriptor
Michael Meskes wrote: It it appears to me that the MSVC build problem has existed for weeks or months but no one noticed so far, right? This is absolutely not true. We have been building ecpg successfully on MSVC all along, just not testing. See for example the make log at http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=red_batdt=2007-09-30%20043002stg=make and search for Project: libecpg The builds only broke 2 or 3 days ago. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
