Re: [HACKERS] WITH RECURSIVE patches 0818
> > Here is new patches fixing the bug you pointed out (patches was > > created by Yoshiyuki). Also I added your SQL to the regression test, > > and now the patches is against CVS HEAD. For your convenience I also > > include patches against the previous version. > > Thanks :) > > Any progress on the READMEs for this? I have posted kind of README (implementation.txt) along with patches on Aug 18. Have you read it? > Also, now that we are into August, would Asaba-san and whomever else > like to try out the git repository? To do so, I just need a login > name and a public key. I will send you later. -- Tatsuo Ishii SRA OSS, Inc. Japan -- 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] WITH RECURSIVE patches 0818
On Sat, Aug 23, 2008 at 11:33:13AM +0900, Tatsuo Ishii wrote: > > I think I may have found another bug: > > > > WITH RECURSIVE t(i,j) AS ( > > VALUES (1,2) > > UNION ALL > > SELECT t2.i, t.j > > FROM ( > > SELECT 2 AS i > > UNION ALL /* Wrongly getting detected, I think */ > > SELECT 3 AS i > > ) AS t2 > > JOIN > > t > > ON (t2.i = t.i) > > ) > > SELECT * FROM t; > > ERROR: attribute number 2 exceeds number of columns 1 > > > > Is there some way to ensure that in the case of WITH RECURSIVE, > > the query to the right of UNION ALL follows only the SQL:2008 > > rules about not having outer JOINs, etc. in it, but otherwise make > > it opaque to the error-checking code? > > > > I know I didn't explain that well, but the above SQL should work > > and the error appears to stem from the parser's looking at the > > innermost UNION ALL instead of the outermost. > > Here is new patches fixing the bug you pointed out (patches was > created by Yoshiyuki). Also I added your SQL to the regression test, > and now the patches is against CVS HEAD. For your convenience I also > include patches against the previous version. Thanks :) Any progress on the READMEs for this? Also, now that we are into August, would Asaba-san and whomever else like to try out the git repository? To do so, I just need a login name and a public key. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-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/22 Hannu Krosing <[EMAIL PROTECTED]>: > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote: >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote: > >> How about we poll -general and see what people say? I'll bet Tom a >> beer that no one replies saying they've created a => operator (unless >> maybe PostGIS uses it). > > Does Oracle use => for "labeled function params" or just named > arguments ? > Oracle use it for named arguments - what I know, similar it doesn't allow functionality as labeled params publicly - SQL/XML use it. >> 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 (). > > I still think that better approach is allowing RECORD as input type and > do all the things Pavel proposed with a function that iterates over > record. > record or hash table - it's implementation - second step. We have to find syntax and semantic now. Pavel > -- > 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/22 Teodor Sigaev <[EMAIL PROTECTED]>: >>> How about we poll -general and see what people say? I'll bet Tom a beer >>> that no one replies saying they've created a => operator (unless maybe >>> PostGIS uses it). > > Hstore uses it: > * text => text - creates hstore type from two text strings > > select 'a'=>'b'; > ?column? > -- > "a"=>"b" > > we should to have flag (or names are in pg_proc already), when function allows named params -etc lot of system functions doesn't named params. So everywhere where function hasn't defined names, then => symbol should by transformed to => operator. ??? Pavel Pavel > -- > Teodor Sigaev E-mail: [EMAIL PROTECTED] > WWW: http://www.sigaev.ru/ > -- 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
I assume there is no TODO here. --- Pavan Deolasee wrote: > (taking the discussions to -hackers) > > On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > > > > > (2) It achieves speedup of VACUUM by pushing work onto subsequent > > regular accesses of the page, which is exactly the wrong thing. > > Worse, once you count the disk writes those accesses will induce it's > > not even clear that there's any genuine savings. > > > > Well in the worst case that is true. But in most other cases, the > second pass work will be combined with other normal activities and the > overhead will be shared, at least there is a chance for that. I think > there is a chance for delaying the work until there is any real need > for that e.g. INSERT or UPDATE on the page which would require a free > line pointer. > > > > (3) The fact that it doesn't work until concurrent transactions have > > gone away makes it of extremely dubious value in real-world scenarios, > > as already noted by Simon. > > > > If there are indeed long running concurrent transactions, we won't get > any benefit of this optimization. But then there are several more > common cases of very short concurrent transactions. In those cases and > for very large tables, reducing the vacuum time is a significant win. > The FSM will be written early and significant work of the VACUUM can > be finished quickly. > > > It strikes me that what you are trying to do here is compensate for > > a bad decision in the HOT patch, which was to have VACUUM's first > > pass prune/defrag a page even when we know we are going to have to > > come back to that page later. What about trying to fix things so > > that if the page contains line pointers that need to be removed, > > the first pass doesn't dirty it at all, but leaves all the work > > to be done at the second visit? I think that since heap_page_prune > > has been refactored into a "scan" followed by an "apply", it'd be > > possible to decide before the "apply" step whether this is the case > > or not. > > > > I am not against this idea. Just that it still requires us double scan > of the main table and that's exactly what we are trying to avoid with > this patch. > > Thanks, > Pavan > > -- > Pavan Deolasee > 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 -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extending grant insert on tables to sequences
Added to September commit fest.
---
Abhijit Menon-Sen wrote:
> At 2008-07-09 15:11:25 -0400, [EMAIL PROTECTED] wrote:
> >
> > No, actually I meant having a lone "list = lappend(list, newseq);" in
> > the loop, so that ExecGrantStmt_oids is called only once.
>
> Yes, I understand what you meant. I just phrased my agreement poorly.
> Here's a more precise phrasing. ;-)
>
> (I agree with Robert Treat that there seems to be no point granting
> SELECT on the sequence. I don't *particularly* care about it, but I
> tend towards wanting to drop that bit. This patch reflects that.)
>
> Jaime: please feel free to use or ignore this, as you wish.
>
> -- ams
>
> diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
> index 15f5af0..8664203 100644
> --- a/src/backend/catalog/aclchk.c
> +++ b/src/backend/catalog/aclchk.c
> @@ -361,6 +361,41 @@ ExecuteGrantStmt(GrantStmt *stmt)
> }
>
> ExecGrantStmt_oids(&istmt);
> +
> + /* If INSERT or UPDATE privileges are being granted or revoked on a
> + * relation, this extends the operation to include any sequences
> + * owned by the relation.
> + */
> +
> + if (istmt.objtype == ACL_OBJECT_RELATION &&
> + (istmt.privileges & (ACL_INSERT | ACL_UPDATE)))
> + {
> + InternalGrant istmt_seq;
> +
> + istmt_seq.is_grant = istmt.is_grant;
> + istmt_seq.objtype = ACL_OBJECT_SEQUENCE;
> + istmt_seq.grantees = istmt.grantees;
> + istmt_seq.grant_option = istmt.grant_option;
> + istmt_seq.behavior = istmt.behavior;
> + istmt_seq.all_privs = false;
> +
> + istmt_seq.privileges = ACL_NO_RIGHTS;
> + if (istmt.privileges & ACL_INSERT)
> + istmt_seq.privileges |= ACL_USAGE;
> + if (istmt.privileges & ACL_UPDATE)
> + istmt_seq.privileges |= ACL_UPDATE;
> +
> + istmt_seq.objects = NIL;
> + foreach (cell, istmt.objects)
> + {
> + istmt_seq.objects =
> + list_concat(istmt_seq.objects,
> +
> getOwnedSequences(lfirst_oid(cell)));
> + }
> +
> + if (istmt_seq.objects != NIL)
> + ExecGrantStmt_oids(&istmt_seq);
> + }
> }
>
> /*
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WITH RECURSIVE patches 0818
> I think I may have found another bug: > > WITH RECURSIVE t(i,j) AS ( > VALUES (1,2) > UNION ALL > SELECT t2.i, t.j > FROM ( > SELECT 2 AS i > UNION ALL /* Wrongly getting detected, I think */ > SELECT 3 AS i > ) AS t2 > JOIN > t > ON (t2.i = t.i) > ) > SELECT * FROM t; > ERROR: attribute number 2 exceeds number of columns 1 > > Is there some way to ensure that in the case of WITH RECURSIVE, the > query to the right of UNION ALL follows only the SQL:2008 rules about > not having outer JOINs, etc. in it, but otherwise make it opaque to > the error-checking code? > > I know I didn't explain that well, but the above SQL should work and > the error appears to stem from the parser's looking at the innermost > UNION ALL instead of the outermost. Here is new patches fixing the bug you pointed out (patches was created by Yoshiyuki). Also I added your SQL to the regression test, and now the patches is against CVS HEAD. For your convenience I also include patches against the previous version. -- Tatsuo Ishii SRA OSS, Inc. Japan recursive_query.patch.gz Description: Binary data *** pgsql/src/backend/executor/nodeAppend.c 2008-08-18 16:20:40.0 +0900 --- pgsql.patched/src/backend/executor/nodeAppend.c 2008-08-23 07:37:29.0 +0900 *** *** 143,152 --- 143,156 int nplans; int i; Plan *initNode; + TupleDesc save_tupledesc; /* check for unsupported flags */ Assert(!(eflags & EXEC_FLAG_MARK)); + /* Save tuple desc */ + save_tupledesc = estate->es_rscan_tupledesc; + /* * Set up empty vector of subplan states */ *** *** 232,237 --- 236,243 appendstate->as_whichplan = appendstate->as_firstplan; exec_append_initialize_next(appendstate); + /* Restore tuple desc */ + estate->es_rscan_tupledesc = save_tupledesc; + return appendstate; } -- 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] Feeding results back into select (was: proposal sql: labeled function params)
On Sat, 23 Aug 2008 00:03:16 +0400 Teodor Sigaev <[EMAIL PROTECTED]> wrote: > select 'a'=>'b'; >?column? > -- >"a"=>"b" Branching the topic, I have a question about this. I haven't studied hstore extensively but this seems like a problem on it's face. Shouldn't you be able to take the result of a select and pass it back to a select? I mean, what happens if you do this? select "a"=>"b"; I suspect that you would get "ERROR: column "a" does not exist" if you do that. What happens when you try to restore a dump? I ran into a similar issue with my chkpass type (see contrib) where the string inserted into the field is stored encrypted with functions to test for equality basically like the Unix password model works. If I just displayed raw strings then a dump and reload would have trashed all the passwords by re-encrypting them. What I did was to make a special case on input. If the string started with ':' then I strip that character and insert the string unchanged. Then I changed the output to prepend the ':'. Now dump and reload work. Just curious. -- 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
How about we poll -general and see what people say? I'll bet Tom a beer that no one replies saying they've created a => operator (unless maybe PostGIS uses it). Hstore uses it: * text => text - creates hstore type from two text strings select 'a'=>'b'; ?column? -- "a"=>"b" -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ -- 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 Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote: > On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote: > How about we poll -general and see what people say? I'll bet Tom a > beer that no one replies saying they've created a => operator (unless > maybe PostGIS uses it). Does Oracle use => for "labeled function params" or just named arguments ? > 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 (). I still think that better approach is allowing RECORD as input type and do all the things Pavel proposed with a function that iterates over record. -- 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] [GENERAL] Surprising syntax error
On Fri, 2008-08-22 at 12:42 -0400, Andrew Dunstan wrote: > depends if you think hacking the bison grammar is a beginner task. It may be anything from beginners task to quite complex . Some things are just copy&paste. - 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] CREATE CAST too strict?
Peter, have you completed this yet? --- Peter Eisentraut wrote: > Am Mittwoch, 9. Juli 2008 schrieb Peter Eisentraut: > > I propose that we relax these two checks to test for binary-coercibility > > instead, which is effectively what is expected and required here anyway. > > Here is the corresponding patch. [ Attachment, skipping... ] > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] convertion from mySQL (mysql_fetch_row)
On Fri, Aug 22, 2008 at 2:20 PM, Masis, Alexander (US SSA) <[EMAIL PROTECTED]> wrote: > People, > I am converting C++ code to Postgres. > Need help on how to deal with mysql_fetch_row, mysql_store_result > functions in Postgres? There should be some C/C++ code available for > these things, I hope. > Thanks, > Alex. http://www.postgresql.org/docs/8.3/interactive/libpq.html in particular, http://www.postgresql.org/docs/8.3/interactive/libpq-exec.html#LIBPQ-EXEC-SELECT-INFO The libpq API is slightly thicker than mysql, which essentially returns char ** for MYSQL_ROW. With pg, you have a lot of flexibility with how you send queries, parameterized, asynchronous, prepared, etc. For starters though you want to look at PQexec which maps to (iirc) mysql_real_query, more or less. libpq has very nice handling of binary data -- the protocol has ability to send and receive blobs (and other things) without escaping -- which is nice. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] convertion from mySQL (mysql_fetch_row)
People, I am converting C++ code to Postgres. Need help on how to deal with mysql_fetch_row, mysql_store_result functions in Postgres? There should be some C/C++ code available for these things, I hope. Thanks, Alex. -- 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] [FINALLY] the TODO list has migrated to Wiki
Euler Taveira de Oliveira wrote: > Hi, > > While we're on this topic, I think we need put a link at [1] heading > directly to (Official) Todo [2]. What we have ATM is "Unofficial Todo > Detail" that is rather inconsistent. We should rename it to "Todo > Detail". Comments? > > [1] http://wiki.postgresql.org/wiki/Development_information > [2] http://wiki.postgresql.org/wiki/Todo Agreed, we used to have an official TODO.detail in CVS but that is gone so I think removing the "Unofficial" word int he title makes sense. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
On Fri, 22 Aug 2008 14:28:57 -0300 Euler Taveira de Oliveira <[EMAIL PROTECTED]> wrote: > Hi, > > While we're on this topic, I think we need put a link at [1] heading > directly to (Official) Todo [2]. What we have ATM is "Unofficial Todo > Detail" that is rather inconsistent. We should rename it to "Todo > Detail". Comments? > > [1] http://wiki.postgresql.org/wiki/Development_information > [2] http://wiki.postgresql.org/wiki/Todo > > To my knowledge we do not have an Official Todo. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- 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] [FINALLY] the TODO list has migrated to Wiki
Hi, While we're on this topic, I think we need put a link at [1] heading directly to (Official) Todo [2]. What we have ATM is "Unofficial Todo Detail" that is rather inconsistent. We should rename it to "Todo Detail". Comments? [1] http://wiki.postgresql.org/wiki/Development_information [2] http://wiki.postgresql.org/wiki/Todo -- Euler Taveira de Oliveira http://www.timbira.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] Solaris ident authentication using unix domain sockets
Garick Hamlin wrote: > On Thu, Jul 03, 2008 at 02:01:22PM -0400, Tom Lane wrote: > > Garick Hamlin <[EMAIL PROTECTED]> writes: > > > I have a patch that I have been using to support postgresql's > > > notion of ident authentication when using unix domain sockets on > > > Solaris. This patch basically just adds support for using > > > getupeercred() on Solaris so unix sockets and ident auth works just > > > like it does on Linux and elsewhere. > > > > Cool. > > > > > + #if defined(HAVE_GETPEERUCRED) > > > + #include > > > + #endif > > > > But this is not cool. There might be systems out there that have > > getpeerucred() but not , and this coding would cause a compile > > failure (even if they actually wouldn't be trying to use getpeerucred() > > because they have some other way to do it). You need an explicit > > configure probe for the header file too, I think. > Ok, I can fix that. Garick, have you made any progress on an updated patch? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Surprising syntax error
depends if you think hacking the bison grammar is a beginner task. cheers andrew Decibel! wrote: Are we still tracking beginner TODOs separately? I'm thinking this falls into that category... Barring objection, I'll mark it as easy. On Aug 21, 2008, at 5:38 PM, Bruce Momjian wrote: Added to TODO: Allow GRANT/REVOKE on views to use the VIEW keyword rather than just TABLE http://archives.postgresql.org/pgsql-hackers/2008-06/msg01133.php --- Bruce Momjian wrote: Marc Munro wrote: -- Start of PGP signed section. The statement: revoke all on view internal.all_objects from public; yields a syntax error. The docs show that the word "view" is not acceptable in this statement which is fine but the surprising thing is that: ? revoke all on table internal.all_objects from public; works fine even though all_objects is a view and not a table. Now that I know about it, this doesn't bother me but it was a surprise and I wonder whether the the parser/planner/whatever should be a bit smarter about allowing the word table to apply to non-tables, and whether the word view ought to be allowed. Yes, I can confirm this behavior on CVS HEAD, and it is odd: test=> CREATE SCHEMA internal; CREATE SCHEMA test=> CREATE VIEW internal.all_objects AS SELECT 1; CREATE VIEW test=> REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC; ERROR: syntax ERROR AT OR near "internal" LINE 1: REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC; ^ test=> REVOKE ALL ON TABLE internal.all_objects FROM PUBLIC; REVOKE Is there a downside to adding "VIEW" in parser/gram.y:privilege_target? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + --Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + --Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers --Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 -- 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] [GENERAL] Surprising syntax error
Decibel! wrote: > Are we still tracking beginner TODOs separately? I'm thinking this > falls into that category... > > Barring objection, I'll mark it as easy. I already had; markers just don't cust/paste easily like they used to. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [DOCS] [ADMIN] shared_buffers and shmmax
On Aug 12, 2008, at 2:43 PM, Greg Smith wrote: On Tue, 12 Aug 2008, Bruce Momjian wrote: There's already some changes needed in this area needed to execute the full GUC cleanup/wizard plan that's being worked on. The pg_settings view really should show the value both as the user input it and as it's stored internally for cases like these, which lowers the confusion here a bit even without going so far as converting everything to bytes. Is this a TODO? I don't think you need yet another TODO for every detail, the existing TODO "Add external tool to auto-tune some postgresql.conf parameters" has to squash a bunch of issues in this area. This particular issue Greg raised will already be improved significantly if executing the larger project plan at http://wiki.postgresql.org/ wiki/GUCS_Overhaul Yeah, but OTOH it's not clear at all when we might see such a tool, while clarifying this stuff would help people immediately... I think a TODO would be good to make sure this doesn't fall through the cracks. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] proposal sql: labeled function params
On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote: 2008/8/20 Tom Lane <[EMAIL PROTECTED]>: "Pavel Stehule" <[EMAIL PROTECTED]> writes: I understand now why Oracle use => symbol for named params. This isn't used so operator - so implementation is trivial. You really didn't understand the objection at all, did you? The point is not about whether there is any built-in operator named =>. The point is that people might have created user-defined operators named that. I understand well, so only I don't see better solution. Yes, everyone who used => should have problems, but it is similar with .. new keywords, etc. Probably easy best syntax doesn't exist :(. I haven't idea who use => now and how often, and if this feature is possible in pg, but there are not technical barriers. How about we poll -general and see what people say? I'll bet Tom a beer that no one replies saying they've created a => operator (unless maybe PostGIS uses it). 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 (). -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] [GENERAL] Surprising syntax error
Are we still tracking beginner TODOs separately? I'm thinking this falls into that category... Barring objection, I'll mark it as easy. On Aug 21, 2008, at 5:38 PM, Bruce Momjian wrote: Added to TODO: Allow GRANT/REVOKE on views to use the VIEW keyword rather than just TABLE http://archives.postgresql.org/pgsql-hackers/2008-06/msg01133.php -- - Bruce Momjian wrote: Marc Munro wrote: -- Start of PGP signed section. The statement: revoke all on view internal.all_objects from public; yields a syntax error. The docs show that the word "view" is not acceptable in this statement which is fine but the surprising thing is that: ? revoke all on table internal.all_objects from public; works fine even though all_objects is a view and not a table. Now that I know about it, this doesn't bother me but it was a surprise and I wonder whether the the parser/planner/whatever should be a bit smarter about allowing the word table to apply to non-tables, and whether the word view ought to be allowed. Yes, I can confirm this behavior on CVS HEAD, and it is odd: test=> CREATE SCHEMA internal; CREATE SCHEMA test=> CREATE VIEW internal.all_objects AS SELECT 1; CREATE VIEW test=> REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC; ERROR: syntax ERROR AT OR near "internal" LINE 1: REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC; ^ test=> REVOKE ALL ON TABLE internal.all_objects FROM PUBLIC; REVOKE Is there a downside to adding "VIEW" in parser/ gram.y:privilege_target? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Improving non-joinable EXISTS subqueries
On Aug 20, 2008, at 12:43 PM, Tom Lane wrote:
We have speculated in the past about having alternative plans that
could be conditionally executed based on information not available
at planning time. This could be seen as a first experiment in that
direction. I am not thinking of a general-purpose AlternativePlan
kind of execution node, because SubPlans aren't actually part of the
main plan-node tree, but an AlternativeSubPlans expression node
type might work.
Something I think we could also use is the ability to grab certain
information before planing takes place. The big case that comes to
mind is:
SELECT ... FROM big_table b JOIN small_lookup_table s USING
(small_lookup_id)
WHERE s.some_name = 'alpha';
... or where we're doing s.some_name IN ('a','b','c'). In many cases,
translating the some_name lookup into actual _id values that you can
then look at in pg_stats for big_table results in a huge improvement
is rowcount estimates. If this is then joining to 5 other tables,
that rowcount information can have a huge impact on the query plan.
Another technique that we could play with is to have the
AlternativeSubPlans node track the actual number of calls it gets,
and switch from the "retail" implementation to the "hashed"
implementation if that exceeds a threshold. This'd provide some
robustness in the face of bad estimates, although of course it's
not optimal compared to having made the right choice to start with.
In many systems, having the most optimal plan isn't that important;
not having a really bad plan is. I expect that giving the executor
the ability to decide the planner made a mistake and shift gears
would go a long way to reducing the impact of bad plans. I wonder if
any other databases have that ability... maybe this will be a first. :)
--
Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
smime.p7s
Description: S/MIME cryptographic signature
Re: [HACKERS] Patch: plan invalidation vs stored procedures
On Aug 20, 2008, at 9:18 AM, Tom Lane wrote: However I have no hard evidence to back up drawing the line there rather than somewhere else. Anyone have data on what sort of DDL changes are common in their applications? I've worked in environments where we used stored functions extensively and where we didn't. Table DDL is generally fairly common in both cases, and if stored functions or views are used, it's very common for table DDL to trigger updates in views and functions. It's fairly common to have to update just functions to kill bugs or change functionality. Trigger changes are a bit less frequent, and views are probably the least frequent. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
On Fri, Aug 22, 2008 at 10:10 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Alvaro Herrera escribió: > >> They did not merge with the text, but they were not searchable. May I >> suggest using the text "[easy]" and "[done]" instead? That way, it is >> searchable, and they don't merge with the text. > > I just made this change. What I now notice is that both markers are > visually not very different. I don't know if this is something worth > fussing about. (Maybe the addition of icons as Brendan was suggesting > would be sufficient visual clue.) > Based on the feedback so far, I have tried for a "best of both worlds" approach. The markers now include icons, which gives us visual distinctiveness, and I've abbreviated the labels to "[D]" and "[E]", which makes it very easy to search. I agreed with Bruce that it was a shame the markers bumped the actual item text over to the right. It looked uneven. So I applied a bit of CSS-fu and got the markers to appear to the left of the items. They now appear in a similar fashion to the bullets in an unordered list. 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] Difference when using ZIC vs. Timezone Abbr - Bug? - SOLVED
Ah.. my definition of MDT was flawed; thanks for the help! Alvaro Herrera wrote: Tom Lane wrote: Dave Witt <[EMAIL PROTECTED]> writes: These two queries produce different output, using version 8.3.3: SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'MDT'; SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'America/Boise'; Why are you surprised? Boise would've been on MST not MDT on that date. i.e. try using MST7MDT instead, which behaves more sanely. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Re: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > ALTER DATABASE ... SET seems to be something that doesn't fit in > > anywhere; I am thinking pg_dump -g should dump it. > > The upthread conclusion was that pg_dump -C should do it. > I am not sure how you come to the conclusion that -g is an > appropriate place, seeing that -g will not create the database(s) > that it'd be trying to apply ALTER to. Agreed, now that I see pg_dump -C. I have added a TODO item: Add: Have pg_dump -C emit ALTER DATABASE ... SET commands after database creation Does the documentation need to be updated beyond my changes from yesterday? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki
A Divendres 22 Agost 2008, Alvaro Herrera va escriure: > Alvaro Herrera escribió: > > They did not merge with the text, but they were not searchable. May I > > suggest using the text "[easy]" and "[done]" instead? That way, it is > > searchable, and they don't merge with the text. > > I just made this change. What I now notice is that both markers are > visually not very different. I don't know if this is something worth > fussing about. (Maybe the addition of icons as Brendan was suggesting > would be sufficient visual clue.) Thanks. Maybe setting [easy] in orange and [done] in green would solve that too. > > -- > Alvaro Herrerahttp://www.CommandPrompt.com/ > The PostgreSQL Company - Command Prompt, Inc. -- Albert Cervera i Areny http://www.NaN-tic.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] Proposal: new border setting in psql
On Fri, 22 Aug 2008 08:23:01 +0200 Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Thu, Aug 21, 2008 at 11:18:24PM -0400, D'Arcy J.M. Cain wrote: > > ReST is nice because it's almost plain text. In fact, a ReST document > > source can easily be read raw. > > I presume by ReST you mean this: > http://docutils.sourceforge.net/rst.html Yes. See the original message in this thread. -- 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
