Re: [HACKERS] proposal sql: labeled function params
2008/8/24 daveg [EMAIL PROTECTED]: On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote: Pavel Stehule [EMAIL PROTECTED] writes: Hello 2008/8/23 Peter Eisentraut [EMAIL PROTECTED]: On Friday 22 August 2008 07:41:30 Decibel! wrote: If we're really worried about it we can have a GUC for a few versions that turns off named parameter assignment. But I don't think we should compromise the design on the theory that some folks might be using that as an operator *and* can't change their application to wrap it's use in (). Even if that were a reasonable strategy, you can't use GUC parameters to alter parser behavior. I thing, so it's possible - in this case. We should transform named params to expr after syntax analyze. So for a bit of useless syntactic sugar we should introduce conflicts with named parameters, conflicts with operators, introduce an un-sqlish syntax and remove a feature users have already made use of and introduce backwards compatibility issues for those users? At any point in this discussion has anyone explained why these labels would actually be a good idea? I was missing that too. What is this for that makes it so compelling? We are talking about two features (or three). 1. Named params (and defaults for params) - allows call function with less params or with params in different order. - default parameters allows decrease size of libraries (number of functions). Using default without named params isn't comfortable (Firebird 2 do it), so we would named params - named params specifies some param has value ..., developer shouldn't specify all params. sure - this functionality is syntactic sugar and are not necessary - it only increase developer's comfort. 2. Labeled params - put some knowledge (labels) about used params into function. This is usable for mainly for serialization and dump function (typical real case is SQL/XML). Other case are custom functions in MySQL - http://www.mysqludf.org/lib_mysqludf_json/index.php , sure - this functionality is syntactic sugar and are not necessary - it only increase developer's comfort. Labels params mean for this value use label. It same as standard keyword AS do it. Labeled params allows explicit labels or implicit labels (column names). Regards Pavel Stehule -dg -- David Gould [EMAIL PROTECTED] 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- 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] Proposal: new border setting in psql
On Sat, 23 Aug 2008 14:57:50 -0400 Tom Lane [EMAIL PROTECTED] wrote: Also, having now looked at the proposed patch, it seems clear that it isn't addressing the issue of quoting/escaping at all; so I wonder how this can be considered to be a safely machine-readable format. It's not a machine readable format. It is a simple display with more border lines. Just like border 2 is like border 1 with more border lines. I'm just following the progression. In particular, the output seems to me to not even approximate the rules laid down at http://docutils.sourceforge.net/docs/user/rst/quickref.html And there is no reason that it should. So, quite aside from the question of whether we care to support ReST, my opinion is that this patch fails to do so, and a significantly more invasive patch would be needed to do it. I suppose it is my fault for mentioning ReST. That was the reason I looked into this but that is not what the final proposal is. I too would argue against making a munged output just to match one formatting scheme. If I do a query and I need to modify it manually when I use it in *any* third party program that's my personal issue. If border 3 happens to get me closer to my format that's great but it has to stand on its own merit. I think that this proopsal does. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] proposal sql: labeled function params
2008/8/23 Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
record or hash table - it's implementation - second step. We have to
find syntax and semantic now.
Why not just use some standard record syntax, like
SELECT(value::type name, ...)
Yeah, that's one way. It also strikes me that hstore itself provides a
usable solution to this problem, though only for simple-string values.
That is, you could do something like
create function myfunc(hstore) returns ...
select myfunc('tag1' = '42' || 'tag2' = 'foobar' || ...);
Or, with the new variadic function support,
create function myfunc(variadic hstore[]) returns ...
select myfunc('tag1' = '42', 'tag2' = 'foobar', ...);
which is just a couple of quote marks away from the syntax Pavel
wants.
it's not far. I am only doesn't know if is it labeled params or named
params :). Using hstore is usable, but I dislike it. There is small
overhead and would to use named params for classic functions - with
different types and fixed count of params. I am thinking so first step
is implementation of defaults without named params like firebird. It's
less controversy.
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] proposal sql: labeled function params
On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
2008/8/23 Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
record or hash table - it's implementation - second step. We have to
find syntax and semantic now.
Why not just use some standard record syntax, like
SELECT(value::type name, ...)
Yeah, that's one way. It also strikes me that hstore itself provides a
usable solution to this problem, though only for simple-string values.
That is, you could do something like
create function myfunc(hstore) returns ...
select myfunc('tag1' = '42' || 'tag2' = 'foobar' || ...);
Or, with the new variadic function support,
create function myfunc(variadic hstore[]) returns ...
select myfunc('tag1' = '42', 'tag2' = 'foobar', ...);
which is just a couple of quote marks away from the syntax Pavel
wants.
it's not far. I am only doesn't know if is it labeled params or named
params :).
This is labeled params, or rather variadic hstore. done this way, it
has added benefit over single hstore param, that key or label can be
repeated:
select myfunc('name' = 'bob', 'age'='42', 'name' = 'bill', ...);
same as
select myfunc2(select('bob' as name, 42 as age, 'bill' as name, ...));
Using hstore is usable, but I dislike it. There is small
overhead and would to use named params for classic functions - with
different types and fixed count of params. I am thinking so first step
is implementation of defaults without named params like firebird. It's
less controversy.
---
Hannu
--
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] Proposal: new border setting in psql
On Sat, 2008-08-23 at 14:42 -0400, Andrew Dunstan wrote: D'Arcy J.M. Cain wrote: On Thu, 21 Aug 2008 21:04:07 -0400 D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: There's still the question of whether this covers any needs that aren't met just as well by XML or CSV output formats. Well, we could remove all the display formats except XML. After all, it can always be converted to any other format. Of course we wouldn't do that. User convenience is all I'm thinking of. Well, Tom has raised a question about its need and Asko has questioned whether it should be under a different setting but so far no one has outright rejected the proposal. Does anyone else have an opinion? I am attaching a patch for further review. In general I think I prefer machine readable formats to be produces by the backend so they are available through all clients, not just psql. ReST is both human-readable format and machine readable format. Where should this come from ? That said, this has sufficiently low impact that I'm not going to be vastly upset if we let it through. I think we should probably confine ourselves to output formats that are in very wide use or we'll be supporting a vast multitude. CSV and XML both qualify here - not sure that ReST does. ReST is just one variant of TEXT - also a format which is in very wide use :) I mean, XML is just a meta-format, like TEXT, unless we start to formalize our XML, provide DTD-s, etc. Hannu -- 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] proposal sql: labeled function params
Hello
2008/8/24 Hannu Krosing [EMAIL PROTECTED]:
On Sun, 2008-08-24 at 08:05 +0200, Pavel Stehule wrote:
2008/8/23 Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
record or hash table - it's implementation - second step. We have to
find syntax and semantic now.
Why not just use some standard record syntax, like
SELECT(value::type name, ...)
Yeah, that's one way. It also strikes me that hstore itself provides a
usable solution to this problem, though only for simple-string values.
That is, you could do something like
create function myfunc(hstore) returns ...
select myfunc('tag1' = '42' || 'tag2' = 'foobar' || ...);
Or, with the new variadic function support,
create function myfunc(variadic hstore[]) returns ...
select myfunc('tag1' = '42', 'tag2' = 'foobar', ...);
which is just a couple of quote marks away from the syntax Pavel
wants.
it's not far. I am only doesn't know if is it labeled params or named
params :).
This is labeled params, or rather variadic hstore. done this way, it
has added benefit over single hstore param, that key or label can be
repeated:
select myfunc('name' = 'bob', 'age'='42', 'name' = 'bill', ...);
same as
select myfunc2(select('bob' as name, 42 as age, 'bill' as name, ...));
and actually, how far we are from original proposal
select myfunc(name = 'bob', age = 42 ...
this syntax is most cleaner, and doesn't need bigger changes in
parser, zero changes in PL
regards
Pavel
Using hstore is usable, but I dislike it. There is small
overhead and would to use named params for classic functions - with
different types and fixed count of params. I am thinking so first step
is implementation of defaults without named params like firebird. It's
less controversy.
---
Hannu
--
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] What in the world is happening on spoonbill?
On Sat, Aug 23, 2008 at 11:44:59PM -0400, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: I'm not sure all browsing setups support tooltips nicely. Any half way modern browser that is not text based should support tool tips. Are we in the business of excluding text-based browsers? Or obsolete ones, for that matter? You need to decide how you want it to appear on such browsers. If you use the alt tag of images, text browsers will simply place the text inline instead of the image. They'd probably ignore the title tag. The title tag is the best, and is widely supported. I'm not sure if any text browsers support CSS, so if implemented that way, for them the tooltips simply won't appear. Once you decide on exactly how you want text browsrs to be able to see it then the solution becomes obvious. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] Proposal: new border setting in psql
On Sun, Aug 24, 2008 at 2:00 AM, D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: On Sat, 23 Aug 2008 14:57:50 -0400 Tom Lane [EMAIL PROTECTED] wrote: Also, having now looked at the proposed patch, it seems clear that it isn't addressing the issue of quoting/escaping at all; so I wonder how this can be considered to be a safely machine-readable format. It's not a machine readable format. It is a simple display with more border lines. Just like border 2 is like border 1 with more border lines. I'm just following the progression. Personally I think it's rather nice to be able to have some extra flexibility in how psql prints out data. Maybe, instead of the dry and uninformative 'border 2', there could be a set of ouput control options. Maybe I want the text aligned but with no border for example. merlin -- 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] [PATCHES] VACUUM Improvements - WIP Patch
On Fri, Aug 22, 2008 at 11:36 PM, Bruce Momjian [EMAIL PROTECTED] wrote: I assume there is no TODO here. Well, there doesn't seem to be a TODO for partial/restartable vacuums, which were mentioned upthread. This is a really desirable feature for big databases and removes one of the reasons to partition large tables. merlin -- 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] Proposal: new border setting in psql
On Sun, 24 Aug 2008 09:16:43 -0400 Merlin Moncure [EMAIL PROTECTED] wrote: Personally I think it's rather nice to be able to have some extra flexibility in how psql prints out data. Maybe, instead of the dry and uninformative 'border 2', there could be a set of ouput control options. Maybe I want the text aligned but with no border for example. You mean like \pset border 0 does? Personally I would love to see user defined display outputs for full flexibility. Since we already have XML I would suggest using that as a base and allow filters to process it before output. That's a much larger job though. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] What in the world is happening on spoonbill?
Are we in the business of excluding text-based browsers? Or obsolete ones, for that matter? I don't think we would want to be in the business of dealing successfully with every quirk of every browser ever released. Another way to look at it is supporting standards: If graphical browsers support at least HTML and CSS, maybe ecmascript, then they are supportable. If text based ones can handle the necessary alt tags then we can also support them. Beyond that, do you really want to document and code around every quirk in MSIE 1.0, Netscape 0.50, or any of the now-extinct text-based browsers for MSDOS? -- Steven Lembark85-09 90th St. Workhorse Computing Woodhaven, NY, 11421 [EMAIL PROTECTED] +1 888 359 3508 -- 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] What in the world is happening on spoonbill?
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: I'm not sure all browsing setups support tooltips nicely. Any half way modern browser that is not text based should support tool tips. Are we in the business of excluding text-based browsers? Or obsolete ones, for that matter? Shrug, I was just offering that most browsers should support it. Joshua D. Drake 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] [PATCHES] VACUUM Improvements - WIP Patch
Merlin Moncure wrote: On Fri, Aug 22, 2008 at 11:36 PM, Bruce Momjian [EMAIL PROTECTED] wrote: I assume there is no TODO here. Well, there doesn't seem to be a TODO for partial/restartable vacuums, which were mentioned upthread. This is a really desirable feature for big databases and removes one of the reasons to partition large tables. I would agree that partial vacuums would be very useful. Joshua D. Drake merlin -- 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] proposal sql: labeled function params
Pavel Stehule [EMAIL PROTECTED] writes: 2008/8/23 Hannu Krosing [EMAIL PROTECTED]: Why not just use some standard record syntax, like do you thing, so is it simpler? It's not about being simpler, it's about pointing out that there are ways to do what you need without creating compatibility problems and without commandeering syntax that, if we were going to commandeer it, would be far better used for named params. IMHO, the use-case for labeled parameters is simply much too narrow to justify giving them special syntax if there is any possible way to avoid it. We have now seen a couple of ways to do it without new syntax, at the cost of a few more lines inside the called function to examine its arguments. But the use-cases you've suggested involve functions that are complicated enough that that's not going to be any big deal. So I feel that the proposal for labeled parameters as such is dead in the water, and that the only usefulness this thread has had is (re-) exploring the syntactic alternatives available for named params. 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] What in the world is happening on spoonbill?
Steven Lembark [EMAIL PROTECTED] writes: Are we in the business of excluding text-based browsers? Or obsolete ones, for that matter? I don't think we would want to be in the business of dealing successfully with every quirk of every browser ever released. That's nothing but a straw-man. The point here was to avoid using constructs that we know won't work on some set of browsers, not to specifically code around any quirks. I already suggested a workable solution that involves no new assumptions at all, which was to put the added info on the linked-to pages instead of directly on the dashboard. Now we could do that *and* use tooltips, if we can be fairly sure that the tooltips will be ignored by browsers that can't handle them as popups. 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] xml plans for postgres?
Recently Postgres has added a data type 'xml' which allows for a well formed document to be inserted as a column in a Postgres database. At the moment it doesnot have much utility, you can *almost* get the same thing done with a text column. It's obviously the first step. Is there a document that describes the direction Postgres will take relative to xml technology? XQuery, XUpdate and XSLT are very different approaches that could compliment or severely disrupt Postgres' evolution. I personally am very excited about the potential but I'd like to get the pulse of the community. Thank you, -g -- Greg Fausak [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Extending error-location reports deeper into the system
We currently have the ability to generate error location pointers, such as regression=# select nosuchcolumn from int8_tbl; ERROR: column nosuchcolumn does not exist LINE 1: select nosuchcolumn from int8_tbl; ^ for grammar-detected syntax errors and for errors during first-level semantic analysis of certain constructs (variables, operators, functions are about all IIRC). Beyond that, it's not possible because we don't include location fields in any node types used in post-parse-analysis query trees. There was some discussion about this back in March in connection with a patch proposed by Peter, and in http://archives.postgresql.org/pgsql-hackers/2008-03/msg00631.php I wrote the current parser location mechanism stores locations only for nodes that appear in raw grammar trees (gram.y output), *not* in analyzed expressions (transformExpr output). This was an intentional choice based on a couple of factors: * Once we no longer have the parser input string available, the location information would be just so much wasted space. * It would add a weird special case to the equalfuncs.c routines: should location fields be compared? (Probably not, but it seems a bit unprincipled to ignore them.) And other places might have comparable uncertainties what to do with 'em. It occurred to me today that one of the foundational assumptions of that old decision has changed, namely that the original query text isn't available after parsing. We have recently fixed things so that it almost always *is* available. So I think a reasonable case can be made for extending most or all querytree node types to include a location field, and then using these fields in the way sketched in the above-referenced message to include location pointers in many more error messages than we do now. The point about equalfuncs behavior isn't bothering me a lot at the moment. It seems clear that we *do* want equal() to ignore location fields, because one of the main purposes it's used for is to note whether, eg, ORDER BY x and GROUP BY x are referring to the same variable, and of course those two occurrences aren't going to have the same syntactic position. Another interesting point is outfuncs/readfuncs behavior. I think that we'd want outfuncs to print the location fields, because they're possibly useful for debugging; but readfuncs should ignore the data and set the fields to -1 (unknown) when reading nodes back in. The reason for this is that the only application for reading nodes in is sucking in stored rules, default expressions, etc. And these are exactly the cases where we indeed no longer have the original source text handy. If we didn't set the locations to unknown, then errors complaining about problems arising within a rule would try to print pointers to locations in the calling query's text having the same offsets as the problematic item had in the original CREATE RULE or similar command. Not what we want. There is going to be some small distributed overhead from adding an additional integer field to so many common Node types, but I find it hard to believe that it'd be measurable. So this all seems doable and probably not a very large task to get the infrastructure in place, though of course actually extending many error messages to include location pointers will probably happen piecemeal over time. Thoughts, objections? If there are none I'm tempted to work on this in the week remaining before September commitfest. 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] Proposal: new border setting in psql
D'Arcy J.M. Cain [EMAIL PROTECTED] writes: On Sat, 23 Aug 2008 14:57:50 -0400 Tom Lane [EMAIL PROTECTED] wrote: So, quite aside from the question of whether we care to support ReST, my opinion is that this patch fails to do so, and a significantly more invasive patch would be needed to do it. I suppose it is my fault for mentioning ReST. That was the reason I looked into this but that is not what the final proposal is. Well, if you can't just paste your output into ReST without having to hand-munge it afterwards, then ISTM the argument for having this additional bit of complexity in our printing routines really falls flat. 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] proposal sql: labeled function params
2008/8/24 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: 2008/8/23 Hannu Krosing [EMAIL PROTECTED]: Why not just use some standard record syntax, like do you thing, so is it simpler? It's not about being simpler, it's about pointing out that there are ways to do what you need without creating compatibility problems and without commandeering syntax that, if we were going to commandeer it, would be far better used for named params. IMHO, the use-case for labeled parameters is simply much too narrow to justify giving them special syntax if there is any possible way to avoid it. We have now seen a couple of ways to do it without new syntax, at the cost of a few more lines inside the called function to examine its arguments. But the use-cases you've suggested involve functions that are complicated enough that that's not going to be any big deal. So I feel that the proposal for labeled parameters as such is dead in the water, and that the only usefulness this thread has had is (re-) exploring the syntactic alternatives available for named params. I feel it too. 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] proposal sql: labeled function params
On Sun, Aug 24, 2008 at 12:00:01PM -0400, Tom Lane wrote: So I feel that the proposal for labeled parameters as such is dead in the water, and that the only usefulness this thread has had is (re-) exploring the syntactic alternatives available for named params. FWIW, I think the way that python manages named and labelled params in a single calling syntax fairly straightforward. http://docs.python.org/tut/node6.html#SECTION00672 Have a ncie day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Please line up in a tree and maintain the heap invariant while boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] Proposal: new border setting in psql
On Sun, 24 Aug 2008 13:22:38 -0400 Tom Lane [EMAIL PROTECTED] wrote: I suppose it is my fault for mentioning ReST. That was the reason I looked into this but that is not what the final proposal is. Well, if you can't just paste your output into ReST without having to hand-munge it afterwards, then ISTM the argument for having this additional bit of complexity in our printing routines really falls flat. But Tom, you are still treating this as a ReST option. Please, pretend that I never mentioned ReST. Consider this simply as a proposal to make a logical extension to the border [0|1|2] setting. If you were going to extend border to 3, what would you do? Adding extra row dividers and turning dashes into equal signs for the existing row divider seems pretty logical on its own without referencing any external formats. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] [PATCHES] VACUUM Improvements - WIP Patch
Joshua D. Drake wrote: Merlin Moncure wrote: Well, there doesn't seem to be a TODO for partial/restartable vacuums, which were mentioned upthread. This is a really desirable feature for big databases and removes one of the reasons to partition large tables. I would agree that partial vacuums would be very useful. I think everyone agrees that partial vacuums would be useful / *A Good Thing* but it's the implementation that is the issue. I was thinking about Alvaro's recent work to make vacuum deal with TOAST tables separately, which is almost like a partial vacuum since it effectively splits the vacuum work up into multiple independent blocks of work, the limitation obviously being that it can only split the work around TOAST. Is there anyway that vacuum could work per relfile since we already split tables into files that are never greater than 1G? I would think that if Vacuum never had more than 1G of work to do at any given moment it would make it much more manageable. -- 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] Extending error-location reports deeper into the system
Tom Lane [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: If we didn't set the locations to unknown, then errors complaining about problems arising within a rule would try to print pointers to locations in the calling query's text having the same offsets as the problematic item had in the original CREATE RULE or similar command. Not what we want. Just an idle thought... we could include the original source text with the rule as well. Though how easy it would be to use when we expand the rule is another question. It would be useful for the recompile view type functionality that people want for cases like adding a column to an underlying table that they're reading in the view with select *. Or people who swap columns around with alter table and want the view to use new columns that now have the old names. It would also be useful for debugging if you're looking at pg_dump output of the reconstructed rule and could compare it with a commented-out original definition to help understand what the original intent was and why it might differ from the current definition. The original objection included caveats that there may be other sites that have uncertainty about whether to include the line number. Are you sure there aren't any? Are you sure there isn't anywhere else lurking that expects equal to really mean equal? Perhaps someplace that builds a list and expects to eliminate duplicates? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS 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] [PATCHES] VACUUM Improvements - WIP Patch
Matthew T. O'Connor [EMAIL PROTECTED] writes: I think everyone agrees that partial vacuums would be useful / *A Good Thing* but it's the implementation that is the issue. I'm not sure how important it will really be once we have support for dead-space-map-driven vacuum. 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] Extending error-location reports deeper into the system
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: If we didn't set the locations to unknown, then errors complaining about problems arising within a rule would try to print pointers to locations in the calling query's text having the same offsets as the problematic item had in the original CREATE RULE or similar command. Not what we want. Just an idle thought... we could include the original source text with the rule as well. Though how easy it would be to use when we expand the rule is another question. Then you'd need some way of keeping track of *which* query string various nodes in the merged query tree were referencing. I'm not willing to go there, at least not in this pass at the problem. The original objection included caveats that there may be other sites that have uncertainty about whether to include the line number. Are you sure there aren't any? Well, if there are, we'll find out when we actually try to do the work. Right now, however, I feel confident that we don't want equality to depend on syntactic position because it never has in the past. 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] What in the world is happening on spoonbill?
Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: Tom Lane wrote: Can you modify the buildfarm's description of that machine to mention the special malloc debug flags? It'd probably stop me from asking you this question again ;-) hmm - would take somebody with SQL-level access to do this - the script to update OS/compiler related data is only partially(ie not updating all information) working... I've changed the compiler to read gcc-malloc-FGJPZ on spoonbill. BTW this animal has not updated in quite a few days ... is this expected? FWIW: this should be fixed now ... 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] xml plans for postgres?
On Sunday 24 August 2008 19:19:24 Greg Fausak wrote: Is there a document that describes the direction Postgres will take relative to xml technology? There is some information at http://wiki.postgresql.org/wiki/XML_Todo, but these items are mainly aiming to complete the approach taken in 8.3. As for major new directions, this is basically up to user demand and contributing resources. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] IN, BETWEEN, spec compliance, and odd operator names
I was looking just now at gram.y's handling of various peculiar SQL
constructs, and was reminded of a point that's bothered me before,
but I don't recall if it's ever been discussed explicitly on -hackers.
As an example, take the production for BETWEEN ASYMMETRIC:
a_expr BETWEEN opt_asymmetric b_expr AND b_expr
{
$$ = (Node *) makeA_Expr(AEXPR_AND, NIL,
(Node *) makeSimpleA_Expr(AEXPR_OP, =, $1, $4, @2),
(Node *) makeSimpleA_Expr(AEXPR_OP, =, $1, $6, @2),
@2);
}
Okay, this is a pretty direct implementation of how SQL99 defines the
construct: 8.3 between predicate syntax rule 6 saith
X BETWEEN ASYMMETRIC Y AND Z is equivalent to X=Y AND X=Z.
But it leaves me feeling dissatisfied. What if the datatype has
standard comparison operators (as identified by a default btree opclass)
but they're not named = and = ? Perhaps more plausibly, what if
those operators exist but aren't in the current search path?
The production for NOT BETWEEN is even more troubling:
a_expr NOT BETWEEN opt_asymmetric b_expr AND b_expr
{
$$ = (Node *) makeA_Expr(AEXPR_OR, NIL,
(Node *) makeSimpleA_Expr(AEXPR_OP, , $1, $5, @2),
(Node *) makeSimpleA_Expr(AEXPR_OP, , $1, $7, @2),
@2);
}
I can't object too much to the hardwired application of DeMorgan's law
(NOT (A AND B) = (NOT A) OR (NOT B)) but what this also has is a
hardwired assumption that and exist and are the negators of
= and = respectively. Probably true, but let's see you find
chapter and verse in the SQL spec to support that...
Seems to me that what this boils down to is whether we want to read the
spec literally (it says the construct is defined in terms of operators
named = and =, therefore we should do that) or by intent (obviously
what they *want* is a construct that behaves sensibly in terms of the
datatype's semantics).
We are more than a bit schizophrenic on this point --- in different
parts of the system you can find these things being done both ways.
There is plenty of code that insists on finding a default btree opclass
to define notions of less or greater; but we have these purely
name-based transformations in gram.y, and I think there are some other
parts of the parser that do similar things.
I'm not particularly eager to start changing things in this area right
now, but it seems to me that it'd be a good idea to establish a project
policy about what we consider to be the preferred behavior, with an eye
to eventually migrating the parts of the system that don't conform.
My own feeling is that we should avoid imputing particular semantics
to particular operator names, and so these constructs should always be
defined by reference to operators found in a default opclass for the
datatype, rather than by specific operator names. However, that way
will likely take more code and cycles to implement than purely
name-based definitions; and there is also the argument that it violates
the in-so-many-words definitions given by the spec.
Comments?
regards, tom lane
PS: there are some other issues here, like whether BETWEEN should be
allowed to cause double evaluation of its left-hand argument, and
whether we wouldn't like it to get reverse-listed by ruleutils.c
in the original BETWEEN format rather than as an expanded version.
However, what I'd like to focus on in this particular thread is the
narrow issue of defining the constructs in terms of operator names
vs operator semantics.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] can't stop autovacuum by HUP'ing the server
I'd like to stop autovac by changing the conf file then sending the server a HUP This appears to work, the logs show autovac terminated by administrative command. Then a few minutes later I see a vacuum process spawned. Is it possible that there are timers that aren't being properly terminated here ? Dave -- 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] can't stop autovacuum by HUP'ing the server
Dave Cramer [EMAIL PROTECTED] writes: I'd like to stop autovac by changing the conf file then sending the server a HUP Uh ... why should that stop an autovac already in progress? I'd only expect it to affect future launches. 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] can't stop autovacuum by HUP'ing the server
Hi Dave, Dave Cramer wrote: I'd like to stop autovac by changing the conf file then sending the server a HUP This appears to work, the logs show autovac terminated by administrative command. Then a few minutes later I see a vacuum process spawned. Is it possible that there are timers that aren't being properly terminated here ? I wonder whether there are tables that need an emergency vacuum (i.e. they have reached the freeze horizon). What version are you running anyway? -- 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] [PATCHES] VACUUM Improvements - WIP Patch
Tom Lane wrote: Matthew T. O'Connor [EMAIL PROTECTED] writes: I think everyone agrees that partial vacuums would be useful / *A Good Thing* but it's the implementation that is the issue. I'm not sure how important it will really be once we have support for dead-space-map-driven vacuum. Is that something we can expect any time soon? I haven't heard much about it really happening for 8.4. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
