Re: [HACKERS] Patch for 8.5, transformationHook
2009/8/9 Alvaro Herrera alvhe...@commandprompt.com: Jeff Davis escribió: On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote: b) it allows constructors for data types (ANSI SQL) datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type Can you describe this case in more detail? What section of SQL are you referring to? Hmm, I see them in 4.7 user-defined types. However what's in SQL2003 and the 2008 draft I have is: 3.1.6.6 constructor function: A niladic SQL-invoked function of which exactly one is implicitly specified for every structured type. An invocation of the constructor function for data type T returns a value V of the most specific type T such that V is not null and, for every observer function O defined for T, the invocation O(V) returns the default value of the attribute corresponding to O. and later: 4.7.4 Constructors Associated with each structured type ST is one implicitly defined constructor function, if and only if ST is instantiable. Let TN be the name of a structured type T. The signature of the constructor function for T is TN() and its result data type is T. The invocation TN() returns a value V such that V is not null and, for every attribute A of T, A(V) returns the default value of A. The most specific type of V is T. For every structured type ST that is instantiable, zero or more SQL-invoked constructor methods can be specified. The names of those methods shall be equivalent to the name of the type for which they are specified. yes - it is Thank You So I'm not seeing those typefields anywhere. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: I takle it back. It's still there at http://archives.postgresql.org/pgsql-hackers/2009-08/msg00485.php posted 3 days ago. Hmm, I think the archive website must be mangling that somehow. What I have in the code I'm reviewing is if (es.format == EXPLAIN_FORMAT_XML) appendStringInfoString(es.str, explain xmlns=\http://www.postgresql.org/2009/explain\;\n); I was planning to complain about the format of this URL --- shouldn't it be more like http://www.postgresql.org/explain/v1 ? --- but there's no semicolon. that url seems too general anyway - can we do something like http://www.postgresql.org/schema/explain/v1 or http://www.postgresql.org/xml/2009/explain/? Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
2009/8/9 Jeff Davis pg...@j-davis.com: On Sun, 2009-07-26 at 15:29 +0200, Pavel Stehule wrote: Hello new patch add new contrib transformations with three modules anotation, decode and json. These modules are ported from my older work. Before applying this patch, please use named-fixed patch too. The hook doesn't need it, but modules anotation and json depend on it. This is not a complete review of the patches, but I have read through the discussion and taken a brief look at the code from a use-case point of view (not a technical review). My general feeling for the use case of the patch is positive. Pavel showed a reasonable variety of valid use cases, and the possibility to make existing special cases (like XML) no longer special cases. However, there are causes for concern: 1. Robert Haas is concerned that the kind of transformations allowed might be too limited: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01947.php gram.y is hard limit of everything what we can do in parser. I thing so there is possible mix two grams together (like enterprisedb do it - integration plpgsql), but still first gram has to have some static entry points - we can't do define new keyword and cannot define new rules, because all is hardly static. It is bison limit. And without changes parser's engine we cannot do some more. I see some possibility in future - to add some like preprocessor for main parser, or postprocessor (for badly processed statements). These creatures allows to define new SQL statement pseudo integrated to core. But this is different task absolutely independent to function transformation hook. But I don't thing so this is real limit. Really I don't would to create new SQL statements now. With hook I am able to work with param list and named param list. This allows lot of games over standard function syntax. 2. Tom Lane is concerned about multiple hooks working together: http://archives.postgresql.org/pgsql-hackers/2009-04/msg01038.php with well written hooks it isn't problem. You can check sample hooks together. I agree, so bad hook can be wrong, but this is general problem of all hooks in postgresql (all hooks in the world). 3. All throughout the thread, there is a general concern that this might not be exactly the right solution. I think we need to wait on this patch. Waiting will hopefully provide better answers to the following questions: * What other similar features exist in the SQL spec that require a similar special case now? If we added this hook, would those still require a special case? * Can anyone think of a better hook or API change that would answer these use cases? If somebody find any general solution different than hook I for it. * Can anyone think of other features that almost fit this model, but that the hook won't quite work for? * If the hook can implement XML, should we refactor the XML support (and COALESCE, etc.) to use the hook for the sake of consistency? If the hook is not good enough for those features, that might indicate a problem. Some XML functions (not all) and COALESCE should be refactorized. But the range for hook is external modules. It's same like executor hooks or some other hooks in PostgreSQL. It's more readable to use direct access to code than hooks when it's possible. Considering that the next commitfest is only about a month away, I don't think that it is too much of a burden to wait. ok I agree. Pavel I didn't have time to do a complete review, so I can't provide much better direction than this right now. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] 2PC state files on shared memory
Michael Paquier michael.paqu...@gmail.com writes: After making a lot of tests, state file size is not more than 600B. In some cases, it reached a maximum of size of 712B and I used such transactions in my tests. I can only say that that demonstrates you didn't test very many cases. It is trivial to generate enormous state files --- try something with a lot of subtransactions, for example, or a lot of files created or deleted. I remain of the opinion that asking users to estimate the amount of shared memory needed for this patch will cripple its usability. We learned that lesson the hard way for FSM, I see no reason we have to fail to learn from experience. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Split-up ECPG patches
Tom Lane wrote: So I'd like to see an actual case made that there's a strong reason for not requiring FROM/IN in ecpg. I guess there's only one, compatibility. Yeah. Are there any other precompilers that actively reject FROM/IN here? If we're just a bit more strict than they are, it's not as bad as if there is no common syntax subset. Oracle: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28427/pc_afemb.htm#i9340 Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
Hello
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the parameters named
and some not)? ISTM that just serves to complicate both the patch
and the user's-eye view, for no real benefit.
consider function like
foo(mandatory params without defaults, optional params with defaults)
because you have to put all mandatory params, then names are needless.
But some optional params you have to specify by names, because without
names, you have to put full params set with respect to rule about
using default params.
CREATE OR REPLACE FUNCTION strtr(a varchar, uppercase boolean = false,
lowercase boolean = false) RETURNS varchar AS $$
BEGIN
IF uppercase and lowercase THEN RAISE EXCEPTION 'cannot use both
modificator together' END IF;
IF uppercase THEN RETURN upper(a); END IF;
IF lowercase THEN RETURN lower(a); END IF;
RETURN a;
END IF;
$$ LANGUAGE plpgsql IMMUTABLE STRICT;
the advice is verbosity:
SELECT strtr('some text',true, false);
versus
SELECT strtr('some text', true AS uppercase);
or
SELECT strtr('some text', true AS lowercase);
With mixed notation is very clean border betwenn mandatory and optional params.
I thing, so without mixed notation this patch hasn't any sense and I
thing it's better to drop it.
Considering that we are worried about someday having to adjust to a
SQL standard in this area, I think we ought to be as conservative as
possible about what we introduce as user-visible features here.
As an example, if they do go with = as the parameter marker,
mixed notation would become a seriously bad idea because it would be
impossible to distinguish incidental use of = as an operator from
mixed notation.
I am sorry, I don't understand. When = should be some operator, then
you cannot distinguish between named notation and positional notation
too. Mixed notation doesn't play any role.
foo(a = 10, b=20) should be code in positional notation much like
named notation. ??? How is difference?
I thing so when some body use operator =, then he have to break
standard notation for some collision situation or for all situation.
Syntax with AS is safe and should be enabled anywhere. We can simply
detect situation where operator = exists and standard named
parameters are allowed.
I thing, so we are on safe side, because we should to support both
syntax, and can disable temporary one ambiguous.
regards
Pavel Stehule
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
Considering that we are worried about someday having to adjust to a SQL standard in this area, I think we ought to be as conservative as possible about what we introduce as user-visible features here. As an example, if they do go with = as the parameter marker, mixed notation would become a seriously bad idea because it would be impossible to distinguish incidental use of = as an operator from mixed notation. I thing, so ANSI will be in conformance with Oracle - so I'll try to check the possibility of the using = as any operator in Oracle regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Ship documentation without intermediate tarballs Documentation
On Monday 10 August 2009 09:26:33 Tom Lane wrote: pet...@postgresql.org (Peter Eisentraut) writes: Ship documentation without intermediate tarballs After this patch, make clean in the doc/src/sgml directory no longer does anything useful. Even make distclean fails to remove all the cruft left behind by a build. This needs to be rethought a bit, else we are going to be shipping tarballs containing junk. make maintainer-clean is supposed to remove everything. make distclean is supposed to remove things that are not supposed to be in the distribution. If you can identifiy something that should not be in the distribution and is not removed by distclean, let me know. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
On Wednesday 05 August 2009 19:59:52 Tom Lane wrote: Or maybe we are going at this the wrong way? Would it be better to try harder to support the write-a-plpgsql-function approach? This would become much simpler if you could just execute plpgsql code instead of having to define a function around it. And perhaps if the plpgsql parser where a bit smarter. Example: RUN LANGUAGE plpgsql $$ FOR schema_name, table_name FROM information_schema.tables WHERE whatever LOOP GRANT ALL ON TABLE schema_name.table_name TO someuser; END LOOP $$; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest reviews and application support
Hi, This commitfest will soon finish and we can already say, I think, that the support software is doing a pretty good job helping through it. Congrats! Now after some discussion about it on IRC, we have some ideas to improve the situation some more. Specifically, reviews are touching several areas and all reviewers aren't comfortable in all of them (it's about skills, time, or perf testing lab equipment, mainly). What about refining what parts of reviewing a specific review touches? Here's a first try at a list of those: - patch (applies, merge, compiles, pass regression) - code reading (looks like it was already there, no WTF?) [1] - documentation (covers code, targets users, is sufficient) - testing (code behavior is what is documented, works well) - creative testing (tried hard to crash it) - perf testing (profiling, no regression in non optimized cases...) - you name it On the application side of things, having checkboxes to check at review submit and little icons on the action lines in general view could do it. When we have that, some reviewers could concentrate on code review only and waits for the patch to have been reviewed first for the other points (patch, documentation, testing, e.g.). And reviewers feeling they won't help reviewing code would omit checking this particular box. Ideas, comments? Regards, -- dim [1] http://www.osnews.com/images/comics/wtfm.jpg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Segmentation fault when using a set-returning C function from a view in 8.4.0
Hello,
I have created a set-returning C function and a view that selects all
the returned rows. When I use SELECT * FROM theview, the returned rows
look fine. But if I use, e.g., SELECT count(*) FROM theview or SELECT
sum(a) FROM theview, I get a segmentation fault.
LOG: server process (PID 7099) was terminated by signal 11:
Segmentation fault
Is this a bug? SELECT count(*), sum(a) FROM thefunction() works fine.
I have created a small example that demonstrates the problem (see
below). If the C function only returns few rows, everything works. If
the function returns more rows (e.g., 5,000), I get the segmentation fault.
I have expericenced this on 8.4.0:
chr=# select version();
version
-
PostgreSQL 8.4.0 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20070115 (SUSE Linux), 64-bit
chr=# show work_mem ;
work_mem
--
256MB
EXAMPLE:
create table demotbl(a int, b int, c int);
create function demosrf() returns setof demotbl language 'c' as
'/tmp/demo.so';
create view demoview as
select * from demotbl
union all
select * from demosrf();
The C code is shown below.
#include postgres.h
#include tupdesc.h
#include funcapi.h
#include fmgr.h
#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
PG_FUNCTION_INFO_V1(demosrf);
Datum
demosrf(PG_FUNCTION_ARGS)
{
ReturnSetInfo *rsinfo = (ReturnSetInfo *)fcinfo-resultinfo;
TupleDesc tupdesc;
Tuplestorestate *tupstore;
AttInMetadata *attinmeta;
int numberOfAttributes;
int i, j;
Datum *values;
bool *isnull;
extern int work_mem;
if(rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo))
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg(Context does not accept a set)));
if(!(rsinfo-allowedModes SFRM_Materialize))
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg(Materialize not allowed)));
tupdesc = rsinfo-expectedDesc;
tupstore = tuplestore_begin_heap(false, false, work_mem);
attinmeta = TupleDescGetAttInMetadata(tupdesc);
numberOfAttributes = attinmeta-tupdesc-natts;
values = (Datum *)palloc(numberOfAttributes * sizeof(Datum));
isnull = (bool *)palloc(numberOfAttributes * sizeof(bool));
// Create rows
for(i = 0; i 1; i++) {
for(j = 0; j numberOfAttributes; j++) {
isnull[j] = false;
values[j] = Int32GetDatum(i);
}
tuplestore_putvalues(tupstore, tupdesc, values, isnull);
}
rsinfo-returnMode = SFRM_Materialize;
rsinfo-setResult = tupstore;
return (Datum)0;
}
Best regards,
Christian Thomsen
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_stat_activity.application_name
On Monday 10 August 2009 08:39:17 Jaime Casanova wrote: On Fri, Jul 17, 2009 at 3:19 AM, Peter Eisentrautpete...@gmx.net wrote: On Thursday 16 July 2009 22:08:25 Kevin Grittner wrote: On the admin list there was a request for an application name column in pg_stat_activity. http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php This is available in a lot of other DBMS products, can be useful to DBAs, and seems pretty cheap and easy. Could we get that onto the TODO list? A facility to show it in the logs (via log_line_prefix probably) would also be useful. is there anyone working on this or have plans to work on this? if not, i will give it a try as soon as this commitfest ends Go for it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Mon, Aug 10, 2009 at 1:56 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Revised patch attached. I'm not convinced this is as good as it can be, but I've been looking at this patch for so long that I'm starting to get cross-eyed, and I'd like to Tom at least have a look at this and assess it before we run out of CommitFest. Committed after significant hacking to try to make the format abstraction layer a tad more complete. Looks nice, thank you. There are still some open issues: * I still think we need a written spec for the non-text output formats. One of the problems with machine reading of the text format is you have to reverse-engineer what the possibilities are, and this patch hasn't made that better. A list of the possible fields, and the possible values for those fields that have finite domains, would be a start. Where would we put this in the documentation? Seems like it might need a new section/chapter somewhere. * There are some decisions that seem a bit questionable to me, like using Parent Relationship tags rather than having the child plans as labeled attributes of the parent node. But I can't really evaluate this for lack of experience with designing XML/JSON structures. That would work for XML, but I think it doesn't for JSON. * As already noted, the URL for the XML schema seems questionable. I think that versioning should go more like v1, v2, ... instead of being tied to a year. Or what about being based on the major PostgreSQL major version? Would it be lame to think about something like http://www.postgresql.org/docs/8.5/static/sql-explain.html ? * I complained earlier that I thought dumping expressions as text was pretty bogus --- it'll leave anything that's trying to do analysis in depth still having to parse complicated stuff. I don't know exactly what I want instead, but at the very least it seems like the variables used in an expression ought to be more readily available. Anyway, it's committed so that people can play with it. We're a lot more likely to get feedback if people actually try to use the feature. Awesome. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Wed, Jul 22, 2009 at 17:05, Magnus Hagandermag...@hagander.net wrote: Dave has built binaries for 8.3.7 and 8.4.0 for this, available at: http://developer.pgadmin.org/~dpage/postgres_exe_virtualalloc-8_3.zip http://developer.pgadmin.org/~dpage/postgres_exe_virtualalloc-8_4.zip We would like as many people as possible to test this both on systems that currently experience the problem and systems that don't, and let us know the status. To test, just replace your current postgres.exe binary with the one in the appropriate ZIP file above. Obviously, take a backup before you do it! These binaries contain just this one patch - the rest of what's been applied to the 8.3 and 8.4 branches for the next minor version is *not* included. It's been a couple of weeks now, and I've had a number of reports both on-list, on-blog and in private, from people using this. I have not yet had a single report of a problem caused by this patch (not counting the case where there was a version mismatch - can't fault the patch for that). Given that, I say we apply this for 8.3 and 8.4 now. Comments? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Multicore builds on MSVC
On Mon, Jul 27, 2009 at 09:11, Magnus Hagandermag...@hagander.net wrote: On Fri, Jul 24, 2009 at 21:33, Dave Pagedp...@pgadmin.org wrote: On Fri, Jul 24, 2009 at 8:07 PM, Magnus Hagandermag...@hagander.net wrote: I'm going to apply this for HEAD. I'm considering backpatching as well, to speed up all build machines. Comments on that? Let's see how it goes in the BF for HEAD, and then backpatch if it looks good. I'm keen to get the potential speedup on 8.3 8.4. Applied to HEAD. Since all buildfarm boxes and my test boxes have handled this without problems, I've backpatched it to 8.4, 8.3 and 8.2. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Andres Freund wrote: I produced/mailed a relaxng version for a a bit older version and I plan to refresh and document it once the format seems suitably stable. I am not sure it is yet. If yes, this should not take that long... (Relaxng because you easily can convert it into most other XML schema description languages) I don't mind doing both, but I think one should be authoritative, and whatever the relative technical merits are (please, let's not debate that here) the fact after quite some years is that XML Schemas have much more traction. See the thread that starts at http://lists.xml.org/archives/xml-dev/200804/msg00058.html. For example, Xerces-J supports XML Schemas natively. Anyway, now it's committed I will be having a play with it. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Monday 10 August 2009 14:39:22 Andrew Dunstan wrote: Andres Freund wrote: I produced/mailed a relaxng version for a a bit older version and I plan to refresh and document it once the format seems suitably stable. I am not sure it is yet. If yes, this should not take that long... (Relaxng because you easily can convert it into most other XML schema description languages) I don't mind doing both, but I think one should be authoritative, and whatever the relative technical merits are (please, let's not debate that here) the fact after quite some years is that XML Schemas have much more traction. See the thread that starts at http://lists.xml.org/archives/xml-dev/200804/msg00058.html. For example, Xerces-J supports XML Schemas natively. I don't really mind which format gets choosen - I just had relaxng one already done. Do you plan to write a XML-Schema Schema? Just to avoid duplicated work... Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Andres Freund wrote: On Monday 10 August 2009 14:39:22 Andrew Dunstan wrote: Andres Freund wrote: I produced/mailed a relaxng version for a a bit older version and I plan to refresh and document it once the format seems suitably stable. I am not sure it is yet. If yes, this should not take that long... (Relaxng because you easily can convert it into most other XML schema description languages) I don't mind doing both, but I think one should be authoritative, and whatever the relative technical merits are (please, let's not debate that here) the fact after quite some years is that XML Schemas have much more traction. See the thread that starts at http://lists.xml.org/archives/xml-dev/200804/msg00058.html. For example, Xerces-J supports XML Schemas natively. I don't really mind which format gets choosen - I just had relaxng one already done. Do you plan to write a XML-Schema Schema? Just to avoid duplicated work... I'll see what I can do. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Adding error message source
On Thu, Aug 6, 2009 at 19:04, Peter Eisentrautpete...@gmx.net wrote: On Thursday 06 August 2009 17:33:40 Tom Lane wrote: I don't think there'd be much logical difficulty in having an output field (ie, CSV column or log_line_prefix escape) that represents a classification of the PID, say as postmaster, backend, AV worker, AV launcher, bgwriter, It would only require changing things in one place, whereas your original proposal seemed mighty open-ended. You might be able to achieve that if you use the %q escape and put something after the %q that you can search for. You could do part of it, but you could still not differ them from each other. And really, it seems very much like a kludge to me. I'd rather have a proper field for it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha releases: How to tag
On Monday 03 August 2009 17:44:32 Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: Does it need a version number change? Maybe just a tag (no branch) is all that is required. I think that we do want the alpha releases to identify themselves as such. And we want a marker in CVS as to what state the alpha release corresponds to. Peter's label-and-undo approach seems like a kluge; and it doesn't scale to consider the possibility that we might want to re-release an alpha after fixing some particularly evil bug. A tag without a branch won't handle that either. I feel that making a branch is the way to go. If we try to get away with a shortcut, we'll probably regret it. Well then, naming: Branch: ??? Tag: REL8_5_ALPHA1 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
On Sunday 09 August 2009 05:21:48 Jeff Davis wrote: * If the hook can implement XML, should we refactor the XML support (and COALESCE, etc.) to use the hook for the sake of consistency? If the hook is not good enough for those features, that might indicate a problem. Well, for 8.4, I proposed to rewrite xmlconcat, which is currently part of that hardcoded XML support, into a variadic function. That was shot down for some unclear backwards compatibility reason. (I guess, someone might have created their own xmlconcat function in a public schema and would now be surprised that it's actually callable?!?) With that in mind, what chances of success will a plan have that proposes to reimplement a bunch of core functionality like COALESCE in user space? Another example that was mentioned during PGCon and that these hooks may or may not be useful for is somehow de-hardcoding various SQL-standard parentheses-less functions such as current_timestamp (thus opening the door for implementing Oracle's sysdate in userspace), but it's again unclear to me whether that would not be objected to if those functions became subject to the schema search path. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
2009/8/10 Peter Eisentraut pete...@gmx.net: On Sunday 09 August 2009 05:21:48 Jeff Davis wrote: * If the hook can implement XML, should we refactor the XML support (and COALESCE, etc.) to use the hook for the sake of consistency? If the hook is not good enough for those features, that might indicate a problem. Well, for 8.4, I proposed to rewrite xmlconcat, which is currently part of that hardcoded XML support, into a variadic function. That was shot down for some unclear backwards compatibility reason. (I guess, someone might have created their own xmlconcat function in a public schema and would now be surprised that it's actually callable?!?) With that in mind, what chances of success will a plan have that proposes to reimplement a bunch of core functionality like COALESCE in user space? Another example that was mentioned during PGCon and that these hooks may or may not be useful for is somehow de-hardcoding various SQL-standard parentheses-less functions such as current_timestamp (thus opening the door for implementing Oracle's sysdate in userspace), but it's again unclear to me whether that would not be objected to if those functions became subject to the schema search path. This patch doesn't help with it. But I thing so we will have other hook in transformation - column name. This hook will serve for detection plpgsql variables in SQL statement. And this hook should be used for some parentheses-less functions. regards Pavel -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
Magnus Hagander mag...@hagander.net writes: It's been a couple of weeks now, and I've had a number of reports both on-list, on-blog and in private, from people using this. I have not yet had a single report of a problem caused by this patch (not counting the case where there was a version mismatch - can't fault the patch for that). Given that, I say we apply this for 8.3 and 8.4 now. Comments? 8.2 as well, no? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Peter Eisentraut pete...@gmx.net wrote: This would become much simpler if you could just execute plpgsql code instead of having to define a function around it. I have often wished for that feature. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: It's been a couple of weeks now, and I've had a number of reports both on-list, on-blog and in private, from people using this. I have not yet had a single report of a problem caused by this patch (not counting the case where there was a version mismatch - can't fault the patch for that). Given that, I say we apply this for 8.3 and 8.4 now. Comments? 8.2 as well, no? 8.2 has a different shmem implementation - the one that emulates sysv shmem. The patch will need to be changed around for that, and I haven't looked at that. It may be worthwhile to do that, but it's a separate patch, so let's get it out in 8.3 and 8.4 first. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Mon, Aug 10, 2009 at 3:33 PM, Magnus Hagandermag...@hagander.net wrote: On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: It's been a couple of weeks now, and I've had a number of reports both on-list, on-blog and in private, from people using this. I have not yet had a single report of a problem caused by this patch (not counting the case where there was a version mismatch - can't fault the patch for that). Given that, I say we apply this for 8.3 and 8.4 now. Comments? 8.2 as well, no? 8.2 has a different shmem implementation - the one that emulates sysv shmem. The patch will need to be changed around for that, and I haven't looked at that. It may be worthwhile to do that, but it's a separate patch, so let's get it out in 8.3 and 8.4 first. Has anyone reported the problem on 8.2? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Mon, Aug 10, 2009 at 16:45, Dave Pagedp...@pgadmin.org wrote: On Mon, Aug 10, 2009 at 3:33 PM, Magnus Hagandermag...@hagander.net wrote: On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: It's been a couple of weeks now, and I've had a number of reports both on-list, on-blog and in private, from people using this. I have not yet had a single report of a problem caused by this patch (not counting the case where there was a version mismatch - can't fault the patch for that). Given that, I say we apply this for 8.3 and 8.4 now. Comments? 8.2 as well, no? 8.2 has a different shmem implementation - the one that emulates sysv shmem. The patch will need to be changed around for that, and I haven't looked at that. It may be worthwhile to do that, but it's a separate patch, so let's get it out in 8.3 and 8.4 first. Has anyone reported the problem on 8.2? Yes. I've seen reports of it all the way back to 8.0. It does seem to have increased in frequently with Win2003 and Win2008 as the server platforms, which means the newer versions have had a higher percentage, but the issue definitely exists. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 1:56 AM, Tom Lanet...@sss.pgh.pa.us wrote:
There are still some open issues:
* I still think we need a written spec for the non-text output formats.
Where would we put this in the documentation? Seems like it might
need a new section/chapter somewhere.
I think it'd be sufficient to put it on the EXPLAIN reference page.
IIRC, the COPY data format is documented on COPY's reference page,
and this is equally particular to a single SQL command.
* There are some decisions that seem a bit questionable to me, like
using Parent Relationship tags rather than having the child plans
as labeled attributes of the parent node. But I can't really evaluate
this for lack of experience with designing XML/JSON structures.
That would work for XML, but I think it doesn't for JSON.
Why not? Something like
Inner: { ... }
fits in JSON AFAICS. I don't know if there are any recognized style
guidelines in the structured-document world that would approve or
deprecate the way you've done it. I do see the advantage that code
can visit all the subplans of a plan without knowing much about the
plan tree structure. What's bothering me the most is that member
subplans of an Append are mushed together with other child plan types.
The ordering of the members is significant. Now the chosen
representation does preserve that order, but ISTM mushing all the
child plan types together like this makes it *look* like the Plans
attribute is unordered; especially when the ordering is in fact
not significant for every other child plan type.
* As already noted, the URL for the XML schema seems questionable.
I think that versioning should go more like v1, v2, ... instead of
being tied to a year.
Or what about being based on the major PostgreSQL major version?
Would it be lame to think about something like
http://www.postgresql.org/docs/8.5/static/sql-explain.html ?
Yeah. In the first place, I imagine the schema will change a few times
before 8.5 is released. In the second, once we do get it right it'll
probably be stable across multiple releases. I think we should just
have a serial number on them, and not assume that either years or
releases are appropriate quantifiers.
* I complained earlier that I thought dumping expressions as text
was pretty bogus --- it'll leave anything that's trying to
do analysis in depth still having to parse complicated stuff.
I don't know exactly what I want instead, but at the very least it
seems like the variables used in an expression ought to be more
readily available.
On this point: basically what's bothering me is that by dumping
expressions as undifferentiated text blobs, we are making the same
mistake in small that this patch is meant to solve in large.
I don't really want to do the work of decomposing expressions right
now, but I'm not happy that it's impossible to do so without a
non-backwards-compatible DTD break. What do you think of emitting
expressions as containers, with the text as the only property?
Instead of
Filter(f1 gt; 0)/Filter
something like
FilterExprText(f1 gt; 0)/Text/Expr/Filter
This would leave room to add additional properties beside the text,
and not break existing clients when we do it.
Another issue that bothers me a bit is the Strategy field.
It may or may not appear depending on Node Type, and when it
does appear, the possible values vary depending on Node Type.
Is that sort of non-orthogonality considered good style?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd escribió: 2009/8/9 Alvaro Herrera alvhe...@commandprompt.com: I noticed an ugly pattern in NUMDesc_prepare calling a cleanup function before every ereport(ERROR). I think it's cleaner to replace that with a PG_TRY block; see attached. Looks nice -- although doesn't have anything to do with the patch so perhaps deserves its own thread? Yes, it just popped up while skimming the patch. I didn't go over the patch in much more detail. (But the numeric_out_sci business got me thinking.) Got you thinking about what? I'd welcome any comments you have. I wondered if it should just return char *. If we want to have this functionality as its own fmgr-blessed function, shouldn't it return text instead of cstring? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Mon, Aug 10, 2009 at 3:49 PM, Magnus Hagandermag...@hagander.net wrote: Has anyone reported the problem on 8.2? Yes. I've seen reports of it all the way back to 8.0. It does seem to have increased in frequently with Win2003 and Win2008 as the server platforms, which means the newer versions have had a higher percentage, but the issue definitely exists. I suppose there's some question of whether this is the kind of issue we need to bother supporting for back-branches. The whole point of supporting back branches is so that people who are already using them can expect to have any known problems they might run into fixed. If people are still running these old branches then presumably their setup isn't prone to this problem. If they're going to update to Win2003 or Win2008 then that's a whole new installation, not an existing installation which might suddenly run into this problem. Is the reason we support old branches so that people can install those old branches in preference to newer ones? Or just so that people who have already installed them can continue to rely on them? The flaws in this line of argument are that a) I'm not entirely sure my premise that someone who has been running fine won't suddenly run into this problem is true. And b) nor am I entirely clear that you have to reinstall Postgres or other apps when you upgrade Windows. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
Magnus Hagander mag...@hagander.net writes: On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote: 8.2 as well, no? 8.2 has a different shmem implementation - the one that emulates sysv shmem. The patch will need to be changed around for that, and I haven't looked at that. It may be worthwhile to do that, but it's a separate patch, so let's get it out in 8.3 and 8.4 first. If it's at all hard to do, I could see deprecating 8.2 for Windows instead. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Alvaro Herrera alvhe...@commandprompt.com writes: Got you thinking about what? I'd welcome any comments you have. I wondered if it should just return char *. If we want to have this functionality as its own fmgr-blessed function, shouldn't it return text instead of cstring? If we expose it at fmgr level it should definitely not return cstring. However, I wasn't foreseeing doing that --- does the submitted patch expose it? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Mon, Aug 10, 2009 at 3:58 PM, Tom Lanet...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote: 8.2 as well, no? 8.2 has a different shmem implementation - the one that emulates sysv shmem. The patch will need to be changed around for that, and I haven't looked at that. It may be worthwhile to do that, but it's a - separate patch, so let's get it out in 8.3 and 8.4 first. If it's at all hard to do, I could see deprecating 8.2 for Windows instead. I could most definitely agree with that on a personal level - no more Mingw/msys builds to maintain :-) Alas, it's probably not practical to drop it without inconveniencing a great many Windows users. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/11 Tom Lane t...@sss.pgh.pa.us: Alvaro Herrera alvhe...@commandprompt.com writes: I wondered if it should just return char *. If we want to have this functionality as its own fmgr-blessed function, shouldn't it return text instead of cstring? If we expose it at fmgr level it should definitely not return cstring. However, I wasn't foreseeing doing that --- does the submitted patch expose it? Sorry, I'm a little hazy on the terminology here. If by expose it at fmgr level you mean did I add it to pg_proc, then no, I didn't. The function is declared in builtins.h as extern Datum numeric_out_sci(PG_FUNCTION_ARGS);, and called from formatting.c using the DirectFunctionCall arrangement. numeric_out_sci() returns using PG_RETURN_CSTRING, same as numeric_out does. If this is the wrong way to expose the function, please let me know and I'll happily fix it. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Kevin Grittner wrote: Peter Eisentraut pete...@gmx.net wrote: This would become much simpler if you could just execute plpgsql code instead of having to define a function around it. I have often wished for that feature. You're not Robinson Crusoe. It could be done in several ways. One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo$ $ LANGUAGE plfoo; We could even default the langauge to plpgsql, for which you would then just need: DO $$ something in plpgsql $$; The something would in effect be treated as a throwaway function taking no parameters and returning void. But to make it really nice you'd have to move away from pl programs as strings. That would be a lot more work, and you really wouldn't want to make it work with more than one PL for the sake of everyone's sanity. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
Dave Page wrote: If it's at all hard to do, I could see deprecating 8.2 for Windows instead. I could most definitely agree with that on a personal level - no more Mingw/msys builds to maintain :-) Alas, it's probably not practical to drop it without inconveniencing a great many Windows users. I hope you're not suggesting we drop Mingw/MSys as a build platform, even if you personally don't want to build with it. I would have found it much harder to do parallel restore for Windows (which works quite differently from Unix, and so had to be specifically developed) if I had been forced to use the MS tool set with which I don't ever otherwise work. I don't think we should deprecate 8.2 on Windows unless we really can't backport this fix reasonably. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd dire...@gmail.com writes: 2009/8/11 Tom Lane t...@sss.pgh.pa.us: If we expose it at fmgr level it should definitely not return cstring. However, I wasn't foreseeing doing that --- does the submitted patch expose it? Sorry, I'm a little hazy on the terminology here. If by expose it at fmgr level you mean did I add it to pg_proc, then no, I didn't. OK. The function is declared in builtins.h as extern Datum numeric_out_sci(PG_FUNCTION_ARGS);, and called from formatting.c using the DirectFunctionCall arrangement. If it's not meant to be in pg_proc, I wouldn't bother with using the V1 call protocol for it. extern char *numeric_out_sci(Numeric x) would be sufficient, and less notation on both caller and callee sides. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Mon, Aug 10, 2009 at 4:29 PM, Andrew Dunstanand...@dunslane.net wrote: I hope you're not suggesting we drop Mingw/MSys as a build platform, even if you personally don't want to build with it. I would have found it much harder to do parallel restore for Windows (which works quite differently from Unix, and so had to be specifically developed) if I had been forced to use the MS tool set with which I don't ever otherwise work. Not at all - in fact we need it to maintain some of the other apps like PostGIS or Slony. I'm just talking about my own use of it for building PG release builds. I don't think we should deprecate 8.2 on Windows unless we really can't backport this fix reasonably. Agreed. There are too many users, and it wouldn't be fair to them. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Andrew Dunstan and...@dunslane.net writes: One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo $$ LANGUAGE plfoo; Yeah, this has been suggested before. I can't see anything very wrong with it. We could even default the langauge to plpgsql, for which you would then just need: DO $$ something in plpgsql $$; Add a GUC variable to set the default language, perhaps? But to make it really nice you'd have to move away from pl programs as strings. That would be a lot more work, and you really wouldn't want to make it work with more than one PL for the sake of everyone's sanity. That would be an awful lot of messiness to save four keystrokes... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Alpha releases: How to tag
daveg da...@sonic.net wrote: When I was at Sybase, changes to the on disk structure were required to provide code to do the migration. Nonetheless, at release time, the migrate process was almost always discovered to be broken, sometimes even before it was shipped to customers. As a long-time user of Sybase SQL Server and it's later incarnation as Adaptive Server Enterprise, I can confirm that the result of this approach was often unsatisfactory from a user perspective. That is, the discovery was not always made before shipping to customers. :-( I have high hopes for pg_migrator, but the pg_dump | psql approach has always worked well for us -- no surprises and no pain beyond the resource management issues. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] join removal
I took at a first crack at coding up an implementation of relation_is_distinct_for() tonight. I am not sure if this will help or not, but on the 8.4 code base we implemented two functions: - getCandidateKeys() - would recursively traverse a tree from a given node to the leaf nodes and determine the candidate keys for the intermediate relation produced by that node - getJoinCard() - determined the join cardinality of a hash join node (1:1, 1:N, etc.) based on the candidate keys of the two input relations It worked pretty well for our tests with equi-joins, but I am sure it is missing many cases. I have attached the code which we used (cardinalityFuncs.c). Some of the helper functions may also be useful (convertUniqueIndexesToCandidateKeys, getJoinAttrs). -- Ramon Lawrence cardinalityFuncs.c Description: cardinalityFuncs.c -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shipping documentation untarred
Peter Eisentraut wrote: So the next step to documentation bliss is to get rid of the man.tar.gz and postgres.tar.gz tarballs that are shipped inside the tarball. These are historical artifacts from the era when building the documentation for release required manual interference, and that era ended yesterday at the latest. Here is how I would like to set this up: * Man pages are built into doc/src/sgml/man1 and doc/src/sgml/man7. This is already happening. * HTML files are built into doc/src/sgml/html. On installation, we just copy that directory. * In doc/src/sgml/Makefile, put Are you sure you don't want the results in doc/src/man1 and doc/src/html? Or even doc/man1 and doc/html? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Adding error message source
Magnus Hagander wrote: On Thu, Aug 6, 2009 at 19:04, Peter Eisentrautpete...@gmx.net wrote: On Thursday 06 August 2009 17:33:40 Tom Lane wrote: I don't think there'd be much logical difficulty in having an output field (ie, CSV column or log_line_prefix escape) that represents a classification of the PID, say as postmaster, backend, AV worker, AV launcher, bgwriter, ?It would only require changing things in one place, whereas your original proposal seemed mighty open-ended. You might be able to achieve that if you use the %q escape and put something after the %q that you can search for. You could do part of it, but you could still not differ them from each other. And really, it seems very much like a kludge to me. I'd rather have a proper field for it. Is this a TODO? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Mon, Aug 10, 2009 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 1:56 AM, Tom Lanet...@sss.pgh.pa.us wrote:
There are still some open issues:
* I still think we need a written spec for the non-text output formats.
Where would we put this in the documentation? Seems like it might
need a new section/chapter somewhere.
I think it'd be sufficient to put it on the EXPLAIN reference page.
IIRC, the COPY data format is documented on COPY's reference page,
and this is equally particular to a single SQL command.
OK, I was just worried it might be long.
* There are some decisions that seem a bit questionable to me, like
using Parent Relationship tags rather than having the child plans
as labeled attributes of the parent node. But I can't really evaluate
this for lack of experience with designing XML/JSON structures.
That would work for XML, but I think it doesn't for JSON.
Why not? Something like
Inner: { ... }
fits in JSON AFAICS. I don't know if there are any recognized style
guidelines in the structured-document world that would approve or
deprecate the way you've done it. I do see the advantage that code
can visit all the subplans of a plan without knowing much about the
plan tree structure. What's bothering me the most is that member
subplans of an Append are mushed together with other child plan types.
The ordering of the members is significant. Now the chosen
representation does preserve that order, but ISTM mushing all the
child plan types together like this makes it *look* like the Plans
attribute is unordered; especially when the ordering is in fact
not significant for every other child plan type.
Oh, I see what you mean. Yeah, we could do that, and I thought about
it. I decided on this, because it would potentially let you recurse
down the tree of nodes without having to handle every kind of
sub-plan-node separately.
* As already noted, the URL for the XML schema seems questionable.
I think that versioning should go more like v1, v2, ... instead of
being tied to a year.
Or what about being based on the major PostgreSQL major version?
Would it be lame to think about something like
http://www.postgresql.org/docs/8.5/static/sql-explain.html ?
Yeah. In the first place, I imagine the schema will change a few times
before 8.5 is released. In the second, once we do get it right it'll
probably be stable across multiple releases. I think we should just
have a serial number on them, and not assume that either years or
releases are appropriate quantifiers.
That's fine then. I'm easy; the schema URL is the least interesting
part of this IMO.
* I complained earlier that I thought dumping expressions as text
was pretty bogus --- it'll leave anything that's trying to
do analysis in depth still having to parse complicated stuff.
I don't know exactly what I want instead, but at the very least it
seems like the variables used in an expression ought to be more
readily available.
On this point: basically what's bothering me is that by dumping
expressions as undifferentiated text blobs, we are making the same
mistake in small that this patch is meant to solve in large.
I don't really want to do the work of decomposing expressions right
now, but I'm not happy that it's impossible to do so without a
non-backwards-compatible DTD break. What do you think of emitting
expressions as containers, with the text as the only property?
Instead of
Filter(f1 gt; 0)/Filter
something like
FilterExprText(f1 gt; 0)/Text/Expr/Filter
This would leave room to add additional properties beside the text,
and not break existing clients when we do it.
Well, there you seem to be adding TWO containers, which is probably
overkill. I could see adding one.
Another issue that bothers me a bit is the Strategy field.
It may or may not appear depending on Node Type, and when it
does appear, the possible values vary depending on Node Type.
Is that sort of non-orthogonality considered good style?
It is in the land of Robert, but someone else might prefer something
different. I'm not attached to doing it this way, but as a guy who
does a lot of database work I tend to prefer to avoid having a
multiple, distinct fields for similar information. It makes it had to
read the SELECT * FROM table output in my 80-character terminal
window. :-)
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Ship documentation without intermediate tarballs Documentation
Peter Eisentraut pete...@gmx.net writes: On Monday 10 August 2009 09:26:33 Tom Lane wrote: After this patch, make clean in the doc/src/sgml directory no longer does anything useful. Even make distclean fails to remove all the cruft left behind by a build. This needs to be rethought a bit, else we are going to be shipping tarballs containing junk. make maintainer-clean is supposed to remove everything. make distclean is supposed to remove things that are not supposed to be in the distribution. If you can identifiy something that should not be in the distribution and is not removed by distclean, let me know. After doing make then make distclean in doc/src/sgml, I see the following undesirable files left behind: -rw-rw-r-- 1 tgl tgl 58 Aug 10 11:51 version.sgml -rw-rw-r-- 1 tgl tgl 38548 Aug 10 11:51 features-unsupported.sgml -rw-rw-r-- 1 tgl tgl 42014 Aug 10 11:51 features-supported.sgml -rw-rw-r-- 1 tgl tgl 345398 Aug 10 11:52 HTML.index -rw-rw-r-- 1 tgl tgl 298859 Aug 10 11:52 bookindex.sgml -rw-rw-r-- 1 tgl tgl 0 Aug 10 11:53 html-stamp I would argue that both make clean and make distclean should remove these. Also, we seem to need .cvsignore entries for the html/ and manN/ subdirectories. IMO the policy for .cvsignore is that anything intentionally left behind by make distclean is to be cvsignore'd. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
On Mon, Aug 10, 2009 at 11:36 AM, Tom Lanet...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo $$ LANGUAGE plfoo; Yeah, this has been suggested before. I can't see anything very wrong with it. We could even default the langauge to plpgsql, for which you would then just need: DO $$ something in plpgsql $$; Add a GUC variable to set the default language, perhaps? But to make it really nice you'd have to move away from pl programs as strings. That would be a lot more work, and you really wouldn't want to make it work with more than one PL for the sake of everyone's sanity. That would be an awful lot of messiness to save four keystrokes... I think it would be awfully handy to integrate some of the features of PL/pgsql into core SQL - especially variables, and also things like IF and FOR... but I'm not expecting it to happen any time soon, or maybe ever. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Robert Haas robertmh...@gmail.com writes: On Mon, Aug 10, 2009 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote: FilterExprText(f1 gt; 0)/Text/Expr/Filter This would leave room to add additional properties beside the text, and not break existing clients when we do it. Well, there you seem to be adding TWO containers, which is probably overkill. I could see adding one. Uh, no, I see one container and a property. If we do just FilterExpr(f1 gt; 0)/Expr/Filter then where do we put additional information about the expression when the time comes? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Split-up ECPG patches
Boszormenyi Zoltan írta:
OK, here's the WIP patch for the unified core/ecpg grammar,
with opt_from_in. But I am still getting the 2 shift/reduce
conflicts exactly for the FORWARD and BACKWARD rules
that I was getting originally. Can you look at this patch and
point me to the right direction in solving it? Thanks in advance.
Okay, I seem to start to succeed with the following strategy.
In ECPG, there's the possibility to ignore certain rules.
I just added these two lines to parse.pl:
$replace_line{'fetch_argsFORWARDopt_from_incursor_name'} = 'ignore';
$replace_line{'fetch_argsBACKWARDopt_from_incursor_name'} = 'ignore';
And I needed to pull up these into FetchStmt as:
FETCH fetch_args FORWARD cursor_name
FETCH fetch_args FORWARD from_in cursor_name
FETCH fetch_args BACKWARD cursor_name
FETCH fetch_args BACKWARD from_in cursor_name
MOVE fetch_args FORWARD cursor_name
MOVE fetch_args FORWARD from_in cursor_name
MOVE fetch_args BACKWARD cursor_name
MOVE fetch_args BACKWARD from_in cursor_name
But I have the following problem. When this is in ecpg.addon:
===
...
ECPG: FetchStmtFETCHfetch_args addon
ECPG: FetchStmtMOVEfetch_args addon
add_additional_variables(current_cursor, false);
free(current_cursor);
current_cursor = NULL;
...
ECPG: FetchStmtMOVEfetch_args rule
| FETCH fetch_args ecpg_into
{
add_additional_variables(current_cursor, false);
free(current_cursor);
current_cursor = NULL;
$$ = cat2_str(make_str(fetch), $2);
}
...
===
After running parse.pl, I get this in preproc.y for FetchStmt:
===
FetchStmt:
FETCH fetch_args
{
add_additional_variables(current_cursor, false);
free(current_cursor);
current_cursor = NULL;
$$ = cat_str(2,make_str(fetch),$2);
}
| MOVE fetch_args
{
add_additional_variables(current_cursor, false);
free(current_cursor);
current_cursor = NULL;
{ // THIS IS AN EXTRA {
$$ = cat_str(2,make_str(move),$2);
}
...
===
With this code, I can prevent the extra { emitted:
===
ECPG: FetchStmtMOVEfetch_args block
{
add_additional_variables(current_cursor, false);
free(current_cursor);
current_cursor = NULL;
$$ = cat2_str(make_str(move), $2);
}
| FETCH fetch_args ecpg_into
{
add_additional_variables(current_cursor, false);
free(current_cursor);
current_cursor = NULL;
$$ = cat2_str(make_str(fetch), $2);
}
...
===
And it bothers me, it looks illegal, but at least ugly.
With the first code, if I delete that extra { manually,
preproc.y compiles fine, and make check in ecpg fails
only one test, and the failure is only in the generated source
as now there's no from emitted in the ECPG-created
statements where FROM or IN doesn't appear in the
*.pgc code, but the stdout/stderr results are the same
as what's expected. Michael, can you give me some help here?
The attached patch uses the second variation, at least it
produces usable preproc.y that compiles into what I wanted.
In the attached patch I added a regression test, as well.
Actually, two, but they are the same, one copy under preproc,
one copy under compat_informix, so the difference in
ECPG runs an be observed.
You had a comment in a previous mail: Some variable
handling commands look suspicious to me, a test case
might alleviate my concerns. I suspect you meant
introducing remove_variable_from_list(). The regression
tesst may help me prove the usefulness of this function,
especially in the FETCH :count FROM :curname; where
multiple $0 references occur, or the PREPARED statement
cases, where the order of the parameters passed to ECPGdo()
would come out reversed, or the dynamic cursor name would
get duplicated in some other statements.
I also tried to test this new code with a varchar cursor,
you're right, it didn't work with cursor name in a varchar
variable. I fixed this case now, reflected in the regression test.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
pg85-dyncursor-unified-grammar-6-ctxdiff.patch.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/11 Tom Lane t...@sss.pgh.pa.us: If it's not meant to be in pg_proc, I wouldn't bother with using the V1 call protocol for it. extern char *numeric_out_sci(Numeric x) would be sufficient, and less notation on both caller and callee sides. Thanks Tom. I have removed the V1 stuff as you suggest, and placed the declaration in numeric.h. Here's version 7. Cheers, BJ _7.diff.bz2 Description: BZip2 compressed data _6-to-7.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Robert Haas escribió: What the hell? I have every version of that patch I've ever submitted in ~/patch/explain-as-submitted, and that extra semicolon is not there in any of them. Furthermore, when I open up the attachment from my sent mail, the semicolon isn't there either. Yet I see it at the link you provided just as clearly as you do. Is there a bug in the archives code??? Hmm, wow, interesting. The mbox from which the archives page is created does _not_ have a semicolon there. A(nother) Mhonarc bug perhaps? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Segmentation fault when using a set-returning C function from a view in 8.4.0
Christian Thomsen c...@cs.aau.dk writes: I have created a set-returning C function and a view that selects all the returned rows. When I use SELECT * FROM theview, the returned rows look fine. But if I use, e.g., SELECT count(*) FROM theview or SELECT sum(a) FROM theview, I get a segmentation fault. LOG: server process (PID 7099) was terminated by signal 11: Segmentation fault Is this a bug? Yeah, in your code: you've violated multiple rules about set-returning functions. Offhand: * using expectedDesc without checking for NULL * creating the tuplestore in the wrong context * failing to set setDesc Also, blindly using expectedDesc instead of constructing your own tuple descriptor is rather badly missing the point. This code will *only* work for a tupdesc consisting of some number of integer columns; if you're passed something else it will fail in more or less horrible ways. What you're supposed to do is construct a tupdesc that accurately describes what you're returning, and use that for the tupstore and pass it back as setDesc. Then the core code can verify it matches expectedDesc. Passing in expectedDesc is only useful for functions that can work with a variety of actual output tupledescriptors. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Mon, Aug 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Aug 10, 2009 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote: FilterExprText(f1 gt; 0)/Text/Expr/Filter This would leave room to add additional properties beside the text, and not break existing clients when we do it. Well, there you seem to be adding TWO containers, which is probably overkill. I could see adding one. Uh, no, I see one container and a property. If we do just FilterExpr(f1 gt; 0)/Expr/Filter then where do we put additional information about the expression when the time comes? I would assume you would just write: FilterText(f1 gt; 0)/TextOther-Stuffthing!/Other-Stuff/Filter ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Uh, no, I see one container and a property. If we do just
FilterExpr(f1 gt; 0)/Expr/Filter
then where do we put additional information about the expression
when the time comes?
I would assume you would just write:
FilterText(f1 gt; 0)/TextOther-Stuffthing!/Other-Stuff/Filter
Perhaps the issue would be clearer in JSON notation. We have
Filter: (f1 0)
What I suggest is
Filter: { Text: (f1 0) }
I don't see where you're going to shoehorn in any additional information
without the container, and once you have the container you need to name
the property, no?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Peter Eisentraut pete...@gmx.net wrote:
reimplement a bunch of core functionality like COALESCE
If such an effort could reduce the astonishment factor for the
following, it would justify a certain amount of effort, in my view:
test=# select pg_typeof('x');
pg_typeof
---
unknown
(1 row)
test=# select pg_typeof(null);
pg_typeof
---
unknown
(1 row)
test=# select pg_typeof(coalesce(null, null));
pg_typeof
---
text
(1 row)
We now have workarounds in place for everywhere this bit us on
conversion to PostgreSQL, but it was actually one of the greater
sources of pain in that process
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Peter Eisentraut pete...@gmx.net wrote:
reimplement a bunch of core functionality like COALESCE
If such an effort could reduce the astonishment factor for the
following, it would justify a certain amount of effort, in my view:
test=# select pg_typeof('x');
pg_typeof
---
unknown
(1 row)
test=# select pg_typeof(null);
pg_typeof
---
unknown
(1 row)
test=# select pg_typeof(coalesce(null, null));
pg_typeof
---
text
(1 row)
The astonishment factor there has nothing to do with how the behavior is
inserted into the parser; it's a property of our type resolution rules.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hot standby - merged up to CVS HEAD
On Sun, 2009-08-09 at 22:15 -0400, Robert Haas wrote: On Sun, Aug 9, 2009 at 2:43 PM, Simon Riggssi...@2ndquadrant.com wrote: I've said very clearly that I am working on this and it's fairly laughable to suggest that anybody thought I wasn't. What more should I do to prove something is active if you won't accept my clearly spoken word? How did you decide I was idle exactly? I think we looked at the fact that you haven't posted an updated version of this patch in almost 6 months. That pretty much covers it. We practice open development, we always have. Those who don't generally run into problems just like this one. Robert has taken the path of being open about the work that is being performed and thus he is the one that appears to be making progress. Simon, regardless of your words you have shown nothing for 6 months. Does that mean you aren't working on it? Of course not but it certainly shows a lack of transparency to the community with the work. You know that doesn't work. The community assumes by default that no patch (or active communication which you also haven't done) means no work. It always has. So instead of all of us bickering, how about we start actively working together on the feature again. Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
On Mon, Aug 10, 2009 at 5:54 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: We now have workarounds in place for everywhere this bit us on conversion to PostgreSQL, but it was actually one of the greater sources of pain in that process Given that pg_typeof() is a relatively new and pg-specific piece of machinery how did this bite you on on your conversion to Postgres some years ago? -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
2009/8/10 Robert Haas robertmh...@gmail.com: On Mon, Aug 10, 2009 at 11:36 AM, Tom Lanet...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo $$ LANGUAGE plfoo; Yeah, this has been suggested before. I can't see anything very wrong with it. We could even default the langauge to plpgsql, for which you would then just need: DO $$ something in plpgsql $$; Add a GUC variable to set the default language, perhaps? But to make it really nice you'd have to move away from pl programs as strings. That would be a lot more work, and you really wouldn't want to make it work with more than one PL for the sake of everyone's sanity. That would be an awful lot of messiness to save four keystrokes... I think it would be awfully handy to integrate some of the features of PL/pgsql into core SQL - especially variables, and also things like IF and FOR... but I'm not expecting it to happen any time soon, or maybe ever. SQL/PSM is better. This language is developed to integration to SQL. It allows one statement procedures. So IF .. THEN ELSE END IF; isn't correct code for PL/pgSQL and it is correct for SQL/PSM. so FOR r AS SELECT * FROM information_schema.tables DO GRANT ON r.table_name TO ...; END FOR; sql/psm doesn't need DECLARE, BEGIN and END in this case; http://www.postgres.cz/index.php/SQL/PSM_Manual regards Pavel Stehule ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hot standby - merged up to CVS HEAD
All, Can we stop arguing about a patch everyone wants? Simon: you have people offering to help with the patch. Offering to help *right now*. Might I suggest that you establish a GIT branch for Hot Standby so that more people can collaborate? Working on it until you get it perfect offsite doesn't work; it's going to require adjustment/debugging once it gets to commitfest anyway. Might as well start that now, or it'll just delay application. Everyone Else: Simon is working hard on this, please get off his back. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hot standby - merged up to CVS HEAD
On Mon, 2009-08-10 at 10:20 -0700, Josh Berkus wrote: All, Can we stop arguing about a patch everyone wants? Simon: you have people offering to help with the patch. Offering to help *right now*. Might I suggest that you establish a GIT branch for Hot Standby so that more people can collaborate? Working on it until you get it perfect offsite doesn't work; it's going to require adjustment/debugging once it gets to commitfest anyway. Might as well start that now, or it'll just delay application. Everyone Else: Simon is working hard on this, please get off his back. I believe that all anyone is asking is that Simon communicate and collaborate. Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Greg Stark gsst...@mit.edu wrote: Given that pg_typeof() is a relatively new and pg-specific piece of machinery how did this bite you on on your conversion to Postgres some years ago? It wasn't the use of pg_typeof which caused us problems, but the types the example demonstrated. Primarily that bit us when our framework substituted values from the application or user selection windows into complex queries, with the result that a coalesce of two NULLs was used in a context where numbers or dates were expected. Our initial hack, which got us up and running fine, was to modify the JDBC driver to substitute a bare NULL for the COALESCE of two NULLs in the JDBC compatibility code which mapped to COALESCE. As a longer- term, less fragile fix we pushed type information deeper into the code making the JDBC requests and had it explicitly wrap a NULL with a CAST. Still, it rates pretty high on my astonishment scale that a COALESCE of two untyped NULLs (or for that matter, any two values of unknown type) returns a text value. It's one of those things which apparently seems unsurprising for those viewing the product from the inside out. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] could not reattach to shared memory on Windows
On Mon, Aug 10, 2009 at 16:58, Tom Lanet...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote: 8.2 as well, no? 8.2 has a different shmem implementation - the one that emulates sysv shmem. The patch will need to be changed around for that, and I haven't looked at that. It may be worthwhile to do that, but it's a separate patch, so let's get it out in 8.3 and 8.4 first. If it's at all hard to do, I could see deprecating 8.2 for Windows instead. I haven't looked at how much work it would be at all yet. So let's do that before we decide to deprecate anything. As mentioned downthread, 8.2 is a very widespread release, and we really want to avoid deprecating it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Mon, Aug 10, 2009 at 12:47 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Uh, no, I see one container and a property. If we do just
FilterExpr(f1 gt; 0)/Expr/Filter
then where do we put additional information about the expression
when the time comes?
I would assume you would just write:
FilterText(f1 gt; 0)/TextOther-Stuffthing!/Other-Stuff/Filter
Perhaps the issue would be clearer in JSON notation. We have
Filter: (f1 0)
What I suggest is
Filter: { Text: (f1 0) }
I don't see where you're going to shoehorn in any additional information
without the container, and once you have the container you need to name
the property, no?
I agree. The JSON looks perfect to me.
I may be thick as a post here and say oh, I'm a moron when you
explain this to me, but I still don't understand why that would
require the XML notation to interpose an intermediate node. Why can't
filter node itself can be the labelled container?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd dire...@gmail.com writes: Thanks Tom. I have removed the V1 stuff as you suggest, and placed the declaration in numeric.h. Here's version 7. Working through this now, and I noticed that the example added to the manual seems to be wrong: entryliteralto_char(0.000485, '9.99')/literal/entry entryliteral' 4.850e-04'/literal/entry With 9.99 as the pattern, I'd expect (and indeed I get) 4.85e-04 not 4.850e-04. This is correct behavior, no? Also, I'm wondering what should happen with regression=# select to_char(0.000485, '99.99'); to_char --- 4.85e-04 (1 row) Doesn't seem quite right. Should we throw error if the number of 9's before the decimal point isn't 1? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Tom Lane escribió: Also, I'm wondering what should happen with regression=# select to_char(0.000485, '99.99'); to_char --- 4.85e-04 (1 row) Doesn't seem quite right. Should we throw error if the number of 9's before the decimal point isn't 1? No, see http://archives.postgresql.org/message-id/4a68fae4.50...@timbira.com -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Robert Haas robertmh...@gmail.com writes: I may be thick as a post here and say oh, I'm a moron when you explain this to me, but I still don't understand why that would require the XML notation to interpose an intermediate node. Why can't filter node itself can be the labelled container? Filter isn't a node; it's a property of the containing Plan node. The way we have this set up, there's a distinction between properties and groups, which AFAICS we have to have in order to have directly comparable structures in XML and JSON. Didn't you design this yourself? (I think part of the issue is that containers in JSON are anonymous whereas XML wants to assign them a named type. That's fine with me, in fact the JSON approach looks rather impoverished.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane escribió: Doesn't seem quite right. Should we throw error if the number of 9's before the decimal point isn't 1? No, see http://archives.postgresql.org/message-id/4a68fae4.50...@timbira.com Ah, nothing like being bug-compatible with a bad implementation. But I agree, if Oracle ignores the number of 9's there then we should too. BTW, this patch adds more NUM_cache_remove() calls. I'm planning to commit it that way, unless you're just about to commit your PG_TRY change? I agree with doing that, but figured it should be a separate commit. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Tom Lane escribió: BTW, this patch adds more NUM_cache_remove() calls. I'm planning to commit it that way, unless you're just about to commit your PG_TRY change? I agree with doing that, but figured it should be a separate commit. No, go ahead, I will commit that separately. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
Robert Haas robertmh...@gmail.com wrote: On Sun, Aug 9, 2009 at 12:27 PM, Tom Lanet...@sss.pgh.pa.us wrote: Now that I've started to read this patch ... exactly what is the argument for allowing a mixed notation (some of the parameters named and some not)? ISTM that just serves to complicate both the patch and the user's-eye view, for no real benefit. Wow, I can't imagine not supporting that. Doesn't every language that supports anything like named parameters also support a mix? Sybase ASE and Microsoft SQL Server support mixed notation (and I think that goes back to their common version 1.0). If a parameter is specified more than once, it is an error. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/11 Tom Lane t...@sss.pgh.pa.us: Working through this now, and I noticed that the example added to the manual seems to be wrong: entryliteralto_char(0.000485, '9.99')/literal/entry entryliteral' 4.850e-04'/literal/entry With 9.99 as the pattern, I'd expect (and indeed I get) 4.85e-04 not 4.850e-04. This is correct behavior, no? Correct. I apologise for the oversight. The example output should lose the trailing zero, or else the example query needs an extra '9' after the decimal point. I don't think it makes much difference which. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Mon, Aug 10, 2009 at 16:10, wader2wad...@jcom.home.ne.jp wrote: Bruce Momjian wrote: I can't reproduce a crash here on BSD: $ pg_standby pg_standby: not enough command-line arguments Can you show us the command and the crash text? I guess this occurs on only windows (Japanese envionment?). C:\Program Files\PostgreSQL\8.4\binpg_standby.exe results no text on command line, Windows error dialog. AppName:pg_standby.exe AppVer:0.0.0.0 ModName:msvcr80.dll ModVer:8.0.50727.762 Offset:91ad I have reproduced this. The problem is: (void) signal(SIGUSR1, sighandler); (void) signal(SIGINT, sighandler); /* deprecated, use SIGUSR1 */ None of these signals exist on WIN32. I think the only reason it compiles at all is that we bring in *some* of our signals emulation code, but certainly not all of it. If I just move those two lines into the #ifndef WIN32 block just around it, it compiles and doesn't crash on running-with-no-arguments. I haven't tried to actually use it though - can someone confirm if this will actually make pg_standby not work properly? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd dire...@gmail.com writes: Here's version 7. Applied with a couple of corrections: the numeric case wasn't dealing with NaNs in the same way as the float cases, and the int8 case was converting to float8 which would lose precision. I made it go through numeric instead, which is pretty expensive but I doubt this is worth expending extra code on. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Still, it rates pretty high on my astonishment scale that a
COALESCE of two untyped NULLs (or for that matter, any two values of
unknown type) returns a text value.
What would you have it do instead, throw an error?
The current behavior is a lot less astonishing for this example:
COALESCE('a', 'b')
which is the same from the type system's point of view.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args
Magnus Hagander mag...@hagander.net writes: If I just move those two lines into the #ifndef WIN32 block just around it, it compiles and doesn't crash on running-with-no-arguments. I haven't tried to actually use it though - can someone confirm if this will actually make pg_standby not work properly? It would mean there's no way to trigger failover via signal. I think what we need is for pg_ctl to be able to send these signals... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PL/Perl crash when using threaded perl
Hi,
I was recently running both pl/perl and pl/perlu functions in a single
session, coming across the error message about failure to allocate a
second Perl interpreter on my platform. I'm running PostgreSQL 8.3.7
built from the sources on Mac OS X 10.5 with perl installed from
macports (macports were synced recently and up-to-date). I've noticed
that threads are not enabled in the macports package.
Then I've reinstalled Perl, enabling a build with threading support,
since the documentation on PL/Perl hinted me on this.
My macports package looks like this:
alexk$ port echo perl5.8 and installed
perl5.8@5.8.9_3+shared+threads
and the Perl flags are:
alexk$ perl -V
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP
USE_FAST_STDIO USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_REENTRANT_API
Built under darwin
Compiled at Aug 10 2009 16:57:14
@INC:
/opt/local/lib/perl5/site_perl/5.8.9/darwin-thread-multi-2level
/opt/local/lib/perl5/site_perl/5.8.9
/opt/local/lib/perl5/site_perl
/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-thread-multi-2level
/opt/local/lib/perl5/vendor_perl/5.8.9
/opt/local/lib/perl5/vendor_perl
/opt/local/lib/perl5/5.8.9/darwin-thread-multi-2level
/opt/local/lib/perl5/5.8.9
Now PL/Perl just crashes a backend even when I try to create a
language itself.
postgres=# create language plperl;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
and gdb tells me this:
Attaching to program: `/usr/local/pgsql/bin/postgres', process 9067.
Reading symbols for shared libraries ++. done
0x9403a749 in recvfrom$UNIX2003 ()
(gdb) c
Continuing.
Reading symbols for shared libraries ... done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004
0x035048f5 in Perl_sv_replace ()
bt full from the running process is attached. Is there a problem with
perl built via macports (I can see both USE_ITHREADS and MULTIPLICITY,
although documentation tells about building with either of them), or
is this a bug in PL/Perl ?
#0 0x035048f5 in Perl_sv_replace ()
No symbol table info available.
#1 0x035209c8 in Perl_leave_scope ()
No symbol table info available.
#2 0x035215fc in Perl_pop_scope ()
No symbol table info available.
#3 0x0352b0ec in Perl_die_where ()
No symbol table info available.
#4 0x034cf462 in Perl_vcroak ()
No symbol table info available.
#5 0x034cf545 in Perl_croak ()
No symbol table info available.
#6 0x034e2d27 in Perl_call_list ()
No symbol table info available.
#7 0x0349a307 in S_process_special_blocks ()
No symbol table info available.
#8 0x034a90d5 in Perl_newATTRSUB ()
No symbol table info available.
#9 0x034a9872 in Perl_utilize ()
No symbol table info available.
#10 0x03495ad0 in Perl_yyparse ()
No symbol table info available.
#11 0x03526e2b in S_doeval ()
No symbol table info available.
#12 0x035307c3 in Perl_pp_entereval ()
No symbol table info available.
#13 0x034e220c in Perl_eval_sv ()
No symbol table info available.
#14 0x034e2295 in Perl_eval_pv ()
No symbol table info available.
#15 0x004e3230 in plperl_init_interp () at plperl.c:445
res = (SV *) 0x852400
embedding = {0x4ec9a2 , 0x4ec9e0 -e, 0x4ec9e4 SPI::bootstrap();
use vars qw(%_SHARED);sub ::plperl_warn { my $msg = shift;$msg =~
s/\\(eval \\d+\\) //g; elog(NOTICE, $msg); } $SIG{__WARN__} =
\\::plperl_warn; sub ::plperl_die { my $msg = s...}
__func__ = plperl_init_interp
#16 0x004e3606 in _PG_init () at plperl.c:214
inited = 0 '\0'
hash_ctl = {
num_partitions = 0,
ssize = 0,
dsize = 0,
max_dsize = 0,
ffactor = 0,
keysize = 64,
entrysize = 68,
hash = 0,
match = 0,
keycopy = 0,
alloc = 0,
hcxt = 0x0,
hctl = 0x0
}
#17 0x00266a8e in internal_load_library (libname=0x84d248
/usr/local/pgsql/lib/plperl.so) at dfmgr.c:296
file_scanner = (DynamicFileList *) 0x852400
load_error = 0x4ec97c \024
stat_buf = {
st_dev = 234881026,
st_ino = 11868721,
st_mode = 33261,
st_nlink = 1,
st_uid = 0,
st_gid = 0,
st_rdev = 0,
st_atimespec = {
tv_sec = 1249929440,
tv_nsec = 0
},
st_mtimespec = {
tv_sec = 1249924863,
tv_nsec = 0
},
st_ctimespec = {
tv_sec = 1249924863,
tv_nsec = 0
},
st_size = 70616,
st_blocks = 144,
st_blksize = 4096,
st_flags = 0,
st_gen = 0,
st_lspare = 0,
st_qspare = {0, 0}
}
__func__ = internal_load_library
#18 0x0026757e in load_external_function (filename=0x852400 \004È,
funcname=0x84d090 plperl_call_handler, signalNotFound=1 '\001',
filehandle=0xbfffdbf8) at dfmgr.c:110
Re: [HACKERS] Shipping documentation untarred
On Monday 10 August 2009 18:43:26 Bruce Momjian wrote: Are you sure you don't want the results in doc/src/man1 and doc/src/html? Or even doc/man1 and doc/html? I am in fact not sure, but people are used to working on doc/src/sgml, so keeping the main action there seemed reasonable. If we ever change VCS, we can move this stuff around and cut out a few directory levels. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shipping documentation untarred
Peter Eisentraut wrote: On Monday 10 August 2009 18:43:26 Bruce Momjian wrote: Are you sure you don't want the results in doc/src/man1 and doc/src/html? Or even doc/man1 and doc/html? I am in fact not sure, but people are used to working on doc/src/sgml, so keeping the main action there seemed reasonable. If we ever change VCS, we can move this stuff around and cut out a few directory levels. I understand that the placement of the generated docs in the sourcedir instead of the builddir is so that it is included in the tarball, correct? I admit I was surprised by that change. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Issues for named/mixed function notation patch
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
I've now read most of this patch, and I think there are some things that
need rework, and perhaps debate about what we want.
1. As I already mentioned, I think the mixed-notation business is a bad
idea. It's unintuitive, it's not especially useful, and it substantially
increases our risk of being semantically incompatible with whatever the
SQL committee might someday do in this area. I think we should disallow
it until we see what they do. I gather that this might be an unpopular
position though.
I disagree. I thing so people expect mainly mixed notation.
2. It doesn't appear that any attention has been given to what happens
if CREATE OR REPLACE FUNCTION is used to change the parameter names of
an existing function. Since the post-analysis representation of parameter
lists is still entirely positional, the actual effect on a function call
in a stored view or rule is nil --- it will still call the same function
it did before, passing the parameters that were originally identified to
be passed. That might be considered good, but it's quite unlike what
will happen to function calls that are stored textually (eg, in plpgsql
functions). Is that what we want? Or should we consider that parameter
names are now part of the API of a function, and forbid CREATE OR REPLACE
FUNCTION from changing them? Or perhaps we should recheck parameter name
matching someplace after analysis, perhaps at default-expansion time?
I can't to imagine some recheck, so I prefer forbid CREATE OR REPLACE
FUNCTION for name change. We should to find some better solution
later. When we immutable names, then we have to have well RENAME
statement in plpgsql.
3. In the same vein, CREATE FUNCTION doesn't disallow duplicate parameter
names, nor functions that have names for some but not all parameters.
The patch appears to cope with the latter case but not the former.
Should we disallow these things in CREATE FUNCTION, or make the patch
never match such functions, or what?
I thing, so duplicate parameter names is clean bug - minimally for
language like plpgsql. I can to imagine some use case in C or plperlu,
but now we have variadic params or arrays, so duplicate names should
be deprecated.
4. No attention has been given to making ruleutils.c list out named or
mixed function calls correctly.
5. I don't like anything about the leaky list representation of
analyzed function arguments. Having null subexpressions in unexpected
places isn't a good idea --- it's likely to cause crashes in code that
isn't being really cautious. Moreover, if we did ultimately support
mixed notation, there's no way to list it out correctly on the basis
of this representation, because you can't tell which arguments were
named and which weren't. I think it would be better to keep the
ArgExprs in the transformed parameter list and have the planner
remove them (and reorder the arguments if needed) when it does
default-argument expansion. Depending on what you think about point
#2, the transformed ArgExprs might need to carry the argument number
instead of the argument name, but in any case they'd just be there
for named arguments. This approach probably will also reduce the
amount of change in the parser, since you won't have to separate
the names from the argument list and pass those all over the place
separately.
I have to look on this - I newer did some changes in planner, so I
know nothing about it now.
Some minor style issues:
* ArgExpr is confusingly named and incorrectly documented, since it's
only used for named arguments. Perhaps NamedArgExpr would be better.
Also, it'd probably be a good idea to include a location field in it
(pointing at the parameter name not the argument expression).
ook
* Most of the PG source code just writes short or long,
not short int. Actually I wonder whether int2 wouldn't
be preferred anyway, since that's how the relevant pg_proc
columns are declared.
ok
* The error messages aren't even approximately conformant to style guide.
* Please avoid useless whitespace changes, especially ones as
ill-considered as this:
***
*** 10028,10034
;
! name: ColId
{ $$ = $1; };
database_name:
ColId
{ $$ = $1; };
--- 10056,10062
;
! name: ColId
{ $$ = $1; };
database_name:
ColId
{ $$ = $1; };
I am sorry, I'll be more careful
I'm going to mark the patch Waiting on Author, since it's not close
to being committable until these issues are resolved.
I spend week out of office, and actually I working on house, but I
hope so tomorrow
Re: [HACKERS] Issues for named/mixed function notation patch
2009/8/9 Tom Lane t...@sss.pgh.pa.us: Oh, another thing: the present restriction that all function parameters after the first one with a default must also have defaults is based on limitations of positional call notation. Does it make sense to relax that restriction once we allow named call notation, and if so what should we do exactly? (This could be addressed in a followup patch, it doesn't necessarily have to be dealt with immediately.) Yes, this rule should be useless. But with the remove of this rule, we have to modify algorithm for positional notation. It depends on this rule. regards Pavel Stehule regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl crash when using threaded perl
Alexey Klyukin wrote: Hi, I was recently running both pl/perl and pl/perlu functions in a single session, coming across the error message about failure to allocate a second Perl interpreter on my platform. I'm running PostgreSQL 8.3.7 built from the sources on Mac OS X 10.5 with perl installed from macports (macports were synced recently and up-to-date). I've noticed that threads are not enabled in the macports package. Then I've reinstalled Perl, enabling a build with threading support, since the documentation on PL/Perl hinted me on this. My macports package looks like this: alexk$ port echo perl5.8 and installed perl5.8@5.8.9_3+shared+threads and the Perl flags are: alexk$ perl -V Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_FAST_STDIO USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under darwin Compiled at Aug 10 2009 16:57:14 @INC: /opt/local/lib/perl5/site_perl/5.8.9/darwin-thread-multi-2level /opt/local/lib/perl5/site_perl/5.8.9 /opt/local/lib/perl5/site_perl /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-thread-multi-2level /opt/local/lib/perl5/vendor_perl/5.8.9 /opt/local/lib/perl5/vendor_perl /opt/local/lib/perl5/5.8.9/darwin-thread-multi-2level /opt/local/lib/perl5/5.8.9 Now PL/Perl just crashes a backend even when I try to create a language itself. postgres=# create language plperl; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. and gdb tells me this: Attaching to program: `/usr/local/pgsql/bin/postgres', process 9067. Reading symbols for shared libraries ++. done 0x9403a749 in recvfrom$UNIX2003 () (gdb) c Continuing. Reading symbols for shared libraries ... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0004 0x035048f5 in Perl_sv_replace () bt full from the running process is attached. Is there a problem with perl built via macports (I can see both USE_ITHREADS and MULTIPLICITY, although documentation tells about building with either of them), or is this a bug in PL/Perl ? I wonder if this is another case of the lack of perl library initialisation bug we have seen before. Can you try with this patch to the postgres 8.3 sources? http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c.diff?r1=1.136;r2=1.136.2.2 We haven't put out an 8.3 release that includes that patch yet. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Still, it rates pretty high on my astonishment scale that a
COALESCE of two untyped NULLs (or for that matter, any two values
of unknown type) returns a text value.
What would you have it do instead, throw an error?
Return a value of unknown type.
The current behavior is a lot less astonishing for this example:
COALESCE('a', 'b')
which is the same from the type system's point of view.
I understand that it is. I see that as a flaw in the implementation.
It would surprise me less if the above resulted in exactly the same
value and type as a bare 'a'.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/10 Tom Lane t...@sss.pgh.pa.us: Brendan Jurd dire...@gmail.com writes: Here's version 7. Applied with a couple of corrections: the numeric case wasn't dealing with NaNs in the same way as the float cases, and the int8 case was converting to float8 which would lose precision. I made it go through numeric instead, which is pretty expensive but I doubt this is worth expending extra code on. regards, tom lane It's nice. I am playing with it, and now I found some potential issue. The parser is maybe too tolerant: postgres=# select to_char(3.14323,'9.9(a'); to_char -- 3.1e+00 (1 row) regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Still, it rates pretty high on my astonishment scale that a
COALESCE of two untyped NULLs (or for that matter, any two values
of unknown type) returns a text value.
What would you have it do instead, throw an error?
Return a value of unknown type.
That would require doing actual computation on values of unknown type.
In the specific case of COALESCE, we could theoretically do that,
since the only computation it needs is IS NULL which is
datatype-independent. In most situations, however, you can't evaluate
the function without knowledge of the datatype semantics. As an
example, consider NULLIF('0', '00'). This gives different answers if
you suppose the literals are text than if you suppose they are integers.
So yeah, we could make COALESCE into a special-case wart in the type
system and have it able to execute without inferring a type for the
arguments. I don't think that would be a net improvement in the
system's astonishment quotient, however; people would just be confused
why COALESCE behaves differently from everything else.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Perl crash when using threaded perl
On Mon, Aug 10, 2009 at 10:09 PM, Andrew Dunstan and...@dunslane.netwrote: I wonder if this is another case of the lack of perl library initialisation bug we have seen before. Can you try with this patch to the postgres 8.3 sources? http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c.diff?r1=1.136;r2=1.136.2.2 We haven't put out an 8.3 release that includes that patch yet. Thanks, Andrew, this patch solved the problem. -- Alexey Klyukin .commandprompt.com The PostgreSQL Company - Command Prompt, Inc
Re: [HACKERS] Patch for 8.5, transformationHook
Tom Lane t...@sss.pgh.pa.us wrote:
In the specific case of COALESCE, we could theoretically do that,
since the only computation it needs is IS NULL which is
datatype-independent.
Well, in the SQL specification, COALESCE is defined as an abbreviation
of the CASE predicate, so to the extent that anyone pays attention to
the spec, this:
COALESCE(a, b)
should be treated identically to:
CASE WHEN a IS NULL THEN a ELSE b END
In most situations, however, you can't evaluate the function without
knowledge of the datatype semantics. As an example, consider
NULLIF('0', '00'). This gives different answers if you suppose the
literals are text than if you suppose they are integers.
That is the other CASE abbreviation. (The only other one.) So,
according to how I read the spec, it should be identical to
CASE WHEN '0' = '00' THEN NULL ELSE '0' END
So yeah, we could make COALESCE into a special-case wart in the type
system and have it able to execute without inferring a type for the
arguments. I don't think that would be a net improvement in the
system's astonishment quotient, however; people would just be
confused why COALESCE behaves differently from everything else.
Not if they notice that COALESCE and NULLIF are documented (quite
properly) on the conditional expressions page, along with the CASE
predicate:
http://www.postgresql.org/docs/8.4/interactive/functions-conditional.html
It is probably a poor choice on the part of the standards committee to
implement these abbreviations for the CASE predicate in a way the
causes them to look so much like functions.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: pgsql: Ship documentation without intermediate tarballs Documentation
Peter Eisentraut wrote: Log Message: --- Ship documentation without intermediate tarballs Documentation files in HTML and man formats are now prepared for distribution using the distprep make target, like everything else. They are placed in doc/src/sgml/html and manX and installed from there by make install, if present. The business with the tarballs in the tarball is gone. Hmm, I notice that this rule to install manpages is pretty slow: for file in /pgsql/source/00head/doc/src/sgml/man1/*.1 /pgsql/source/00head/doc/src/sgml/man3/*.3 /pgsql/source/00head/doc/src/sgml/man7/*.7; do /bin/sh /pgsql/source/00head/config/install-sh -c -m 644 $file /pgsql/install/00head/share/man/`echo $file | sed 's,^/pgsql/source/00head/doc/src/sgml/,,'` || exit; done Can we use basename here instead of the `echo | sed` hack? Hmm, oh, I see it's stripping everything except the last directory level. I guess I'd go for doing a simple cp inside each man directory. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
I wrote: COALESCE(a, b) should be treated identically to: CASE WHEN a IS NULL THEN a ELSE b END In case it's not obvious that the above has a typo, I meant: CASE WHEN a IS NOT NULL THEN a ELSE b END -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Robert Haas robertmh...@gmail.com writes: On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com wrote: new patch add new contrib transformations with three modules anotation, decode and json. These are pretty good examples, but the whole thing still feels a bit grotty to me. The set of syntax transformations that can be performed with a hook of this type is extremely limited - in particular, it's the set of things where the parser thinks it's valid and that the structure is reasonably similar to what you have in mind, but the meaning is somewhat different. The fact that two of your three examples require your named and mixed parameters patch seems to me to be evidence of that. I finally got around to looking at these examples, and I still don't find them especially compelling. Both the decode and the json example could certainly be done with regular function definitions with no need for this hook. The = to AS transformation maybe not, but so what? The reason we don't have that one in core is not technological. The really fundamental problem with this hook is that it can't do anything except create syntactic sugar, and a pretty darn narrow class of syntactic sugar at that. Both the raw parse tree and the transformed tree still have to be valid within the core system's understanding. What's more, since there's no hook in ruleutils.c, what is going to come out of the system (when dumping, examining a view, etc) is the transformed expression --- so you aren't really hiding any complexity from the user, you're just providing a one-time shorthand that will be expanded into a notation he also has to be familiar with. Now you could argue that we've partly created that restriction by insisting that the hook be in transformFuncCall and not transformExpr. But that only restricts the subset of raw parse trees that you can play with; it doesn't change any of the other restrictions. Lastly, I don't think the problem of multiple hook users is as easily solved as Pavel claims. These contrib modules certainly fail to solve it. Try unloading (or re-LOADing) them in a different order than they were loaded. So on the whole I still think this is a solution looking for a problem, and that any problems it could solve are better solved elsewhere. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
In the specific case of COALESCE, we could theoretically do that,
since the only computation it needs is IS NULL which is
datatype-independent.
Well, in the SQL specification, COALESCE is defined as an abbreviation
of the CASE predicate, so to the extent that anyone pays attention to
the spec, this:
COALESCE(a, b)
should be treated identically to:
CASE WHEN a IS NULL THEN a ELSE b END
... as indeed we do. That CASE will be handled the same way as the
COALESCE is, ie, resolve as text output for lack of a better idea.
In most situations, however, you can't evaluate the function without
knowledge of the datatype semantics. As an example, consider
NULLIF('0', '00'). This gives different answers if you suppose the
literals are text than if you suppose they are integers.
That is the other CASE abbreviation. (The only other one.) So,
according to how I read the spec, it should be identical to
CASE WHEN '0' = '00' THEN NULL ELSE '0' END
Yes, and you're begging the question: what are the semantics
of that = operator? Without imputing a datatype to the literals,
you can't resolve it.
It is probably a poor choice on the part of the standards committee to
implement these abbreviations for the CASE predicate in a way the
causes them to look so much like functions.
Whether it's a function has nothing to do with this. It's a question of
datatype-dependent semantics, and it would be the same no matter what
the visual appearance of the constructs was.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Mon, Aug 10, 2009 at 1:45 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I may be thick as a post here and say oh, I'm a moron when you
explain this to me, but I still don't understand why that would
require the XML notation to interpose an intermediate node. Why can't
filter node itself can be the labelled container?
Filter isn't a node; it's a property of the containing Plan node.
My use of the word node was poorly chosen, since that word has a
specific meaning in the context of PG.
The way we have this set up, there's a distinction between properties
and groups, which AFAICS we have to have in order to have directly
comparable structures in XML and JSON. Didn't you design this
yourself?
Yes, I did. But the point is that as far as I can see, the following
two things are equivalent:
FilterText(f1 gt; 0)/Text/Filter
Filter: { Text: (f1 0) }
And this is not:
FilterExprText(f1 gt; 0)/Text/Expr/Filter
The latter would be equivalent to something like this in JSON:
Filter : { Expr : { Text: (f1 0) } }
or if you intended the Expr thing to be an array-type container,
then it would be equivalent to this:
Filter : { [ { Text: (f1 0) } ] }
Would it be helpful for me to try to reduce this to code?
(I think part of the issue is that containers in JSON are anonymous
whereas XML wants to assign them a named type. That's fine with me,
in fact the JSON approach looks rather impoverished.)
That does make things a little tricky, though it has the virtue of
mapping nicely onto data structures other than XML.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Mon, Aug 10, 2009 at 20:44, Tom Lanet...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: If I just move those two lines into the #ifndef WIN32 block just around it, it compiles and doesn't crash on running-with-no-arguments. I haven't tried to actually use it though - can someone confirm if this will actually make pg_standby not work properly? It would mean there's no way to trigger failover via signal. I think what we need is for pg_ctl to be able to send these signals... Those signals don't *exist* on Windows. The whole idea of cross-process signals don't *exist* on Windows. We emulate it in the main backend, by creating a background thread that sets a global variable. That is then polled in the CHECK_FOR_INTERRUPTS macro. pg_ctl is perfectly capable of sending these signals, but pg_standby can't receive them. We could implement the same type of check in pg_standby, but it requires something like CHECK_FOR_INTERRUPTS. And these interrupts won't, by default, cause any kind of interruption of the process. In the backend, we interrupt socket calls because we have the socket wrapper layer, and nothing else. I don't know how doable this would be in pg_standby - does it always block on a single thing where we could stick some win32 synchronization code? If it's a single, or limited, places we could implement something similar to the backend. But if we need to interrupt at arbitrary locations, that's just not possible. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: [Correcting typo below.] Well, in the SQL specification, COALESCE is defined as an abbreviation of the CASE predicate, so to the extent that anyone pays attention to the spec, this: COALESCE(a, b) should be treated identically to: CASE WHEN a IS [NOT] NULL THEN a ELSE b END ... as indeed we do. That CASE will be handled the same way as the COALESCE is, ie, resolve as text output for lack of a better idea. I'm surprised to find that CASE behaves this way, too. At least there's an internal consistency to this, even if I think it's wrong on all counts. test=# select pg_typeof(case when null is not null then null else null end); pg_typeof --- text (1 row) I think the better idea is to say that the type is still unknown. That is the other CASE abbreviation. (The only other one.) So, according to how I read the spec, it should be identical to CASE WHEN '0' = '00' THEN NULL ELSE '0' END Yes, and you're begging the question: what are the semantics of that = operator? Without imputing a datatype to the literals, you can't resolve it. Yeah -- my argument would be that the = operator in NULLIF should be treated the same as if the function-like abbreviation were rewritten to the full CASE predicate. It doesn't surprise me that that is taken as text, given that they are both unadorned character string literals. The surprise here (for me at least) that the following generates a null of type text instead of matching the non-NULL input argument or (failing that) unknown, assuming the rewrite of NULLIF(a, b) to the equivalent CASE predicate: test=# select pg_typeof(case when null = 0 then null else null end); pg_typeof --- text (1 row) Frankly, I'm dubious about treating a character string literal as being of unknown type in the first place, but I can see where it is a useful convenience. Where the wheels really come off for me is in automagically going from unknown type to text on any form of CASE predicate. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: But to make it really nice you'd have to move away from pl programs as strings. That would be a lot more work, and you really wouldn't want to make it work with more than one PL for the sake of everyone's sanity. You mean something like: postgres=# begin ... end; ? That would be an awful lot of messiness to save four keystrokes... I second that. We support that in EDB for Oracle compatibility, and it's a pain the ass. You need to call the PL/pgSQL parser on the query string just to figure out where it ends. And worse, psql needs to know about it too, so you need a minimal version of the PL/pgSQL parser in the client too. Something like DO $$ begin ...; end $$; gives 90% of the usability with 10% of the trouble. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Kevin Grittner kevin.gritt...@wicourts.gov wrote: Yeah -- my argument would be that the = operator in NULLIF should be treated the same as if the function-like abbreviation were rewritten to the full CASE predicate. It doesn't surprise me that that is taken as text, given that they are both unadorned character string literals. The surprise here (for me at least) that the following generates a null of type text instead of matching the non-NULL input argument or (failing that) unknown, assuming the rewrite of NULLIF(a, b) to the equivalent CASE predicate: test=# select pg_typeof(case when null = 0 then null else null end); pg_typeof --- text (1 row) Symmetry fails here -- NULLIF is *not* treated the same as the CASE predicate for which it is the abbreviation, which is arguably a bug-level deviation from the SQL standard. Compare the above to: test=# select nullif(null, 0); nullif (1 row) -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Heikki Linnakangas wrote: Something like DO $$ begin ...; end $$; gives 90% of the usability with 10% of the trouble. Yes, I think that's the consensus. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for 8.5, transformationHook
Resending to correct a copy/paste error. Apologies. Kevin Grittner kevin.gritt...@wicourts.gov wrote: Yeah -- my argument would be that the = operator in NULLIF should be treated the same as if the function-like abbreviation were rewritten to the full CASE predicate. It doesn't surprise me that that is taken as text, given that they are both unadorned character string literals. The surprise here (for me at least) that the following generates a null of type text instead of matching the non-NULL input argument or (failing that) unknown, assuming the rewrite of NULLIF(a, b) to the equivalent CASE predicate: test=# select pg_typeof(case when null = 0 then null else null end); pg_typeof --- text (1 row) Symmetry fails here -- NULLIF is *not* treated the same as the CASE predicate for which it is the abbreviation, which is arguably a bug-level deviation from the SQL standard. Compare the above to: test=# select pg_typeof(nullif(null, 0)); pg_typeof --- integer (1 row) Which is the result I would want and expect, but is inconsistent with treating it as an abbreviation of CASE. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Something like DO $$ begin ...; end $$; gives 90% of the usability with 10% of the trouble. I'd be a big fan of this. Especially if we could at an \e for it in psql. \ec? I'm not agreeing, though, that we don't need a GRANT ALL/ALTER DEFAULT. We still need that for the simplest cases so that novice-level users will use *some* access control. But it would mean that we wouldn't need GRANT ALL/ALTER DEFAULT to support anything other than the simplest cases. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
* Josh Berkus (j...@agliodbs.com) wrote: I'm not agreeing, though, that we don't need a GRANT ALL/ALTER DEFAULT. We still need that for the simplest cases so that novice-level users will use *some* access control. But it would mean that we wouldn't need GRANT ALL/ALTER DEFAULT to support anything other than the simplest cases. I agree with Josh. That's also why I feel the schema or namespace-driven grant/defaults make the most sense. I feel like it's the most natural and intuitive option. Having a default for roles is a neat idea, but I don't believe they'd be used much and would require having a precedence or merging them, neither of which I like. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Robert Haas escribió: But if there are patches against that code, then they've been broken now and they will break again when the pgindent run is done. If the indentation is fixed at commit-time (or before someone goes to the trouble of fixing them), then they get broken only once. I guess it's not the end of the world, but it sure seems like the less work pgindent does when it is run, the better. I think that we should be looking at making pgindent runnable by lone hackers at home in their patched trees. That way they fix their patches by simply running it when it's run on the CVS tree, before doing an update. That should remove/reduce the merge problems. ... at least in CVS; not sure what would happen if this was done in a GIT repository. (It would probably require a rebase, but then what do I know about GIT?). BTW I think it's better to redirect this kind of discussion to -hackers. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hot standby - merged up to CVS HEAD
On Mon, 2009-08-10 at 10:20 -0700, Josh Berkus wrote: Simon: you have people offering to help with the patch. Offering to help *right now*. Might I suggest that you establish a GIT branch for Hot Standby so that more people can collaborate? Working on it until you get it perfect offsite doesn't work; it's going to require adjustment/debugging once it gets to commitfest anyway. Might as well start that now, or it'll just delay application. Agreed, but there will be some time before that is possible. I'm happy to commit to Sept 15 *latest* to do the above. I know what has to be done and that's my timescale for doing it. Everyone Else: Simon is working hard on this, please get off his back. Thanks, good plan. There is absolutely no danger this patch is going to be delayed and there is really no call for haste. I near killed myself trying to get it into 8.4 and I would like to avoid a tension-fest this time around. We have time and intend to take it at a reasonable pace, and spend time thinking first, then talking later. Over and out, for now. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
