Re: [HACKERS] [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Heikki Linnakangas wrote: KaiGai Kohei wrote: However, ACL_UPDATE and ACL_SELECT_FOR_UPDATE internally shares same bit so SE-PostgreSQL cannot discriminate between UPDATE and SELECT FOR UPDATE or SHARE. Why should it discriminate between them? Typically, we cannot set up a foreign-key which refers a primary-key within read-only table from SELinux's viewpoint. The vanilla access control mechanism switches the current userid, and it enables to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model does not have a concept of ownership. Thanks, -- KaiGai Kohei kai...@kaigai.gr.jp -- 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] 8.4b1: Query returning results in different order to 8.3
Greg Stark wrote: UNION ALL should still preserve the order of the subqueries. It just returns all the rows of each subquery one after the other with no other work. Although without an ORDER BY that's not well-defined and thus not guaranteed to work in future versions either. I doubt we're going to change that anytime soon, but I wouldn't rely on it in an application. -- 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] unalias of ACL_SELECT_FOR_UPDATE
KaiGai Kohei wrote: However, ACL_UPDATE and ACL_SELECT_FOR_UPDATE internally shares same bit so SE-PostgreSQL cannot discriminate between UPDATE and SELECT FOR UPDATE or SHARE. Why should it discriminate between them? -- 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
[HACKERS] Recursive plpgsql function in rule
I am trying to select subtree by parent id in table: create table categories( id int, parent_id int ); I am fetching it by recursive plpgsql function, which works well. When i use that function as part of rule operation, i am getting ERROR: stack depth limit exceeded. I have tried to rewrite without recursion which cause infinite loop in rule. Is it possible to sent dynamic structures in planer? Or how to fetch subtree without change of table structure inside rule? Thanks -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Reference on partial data
Hi, is it possible to create reference constraint only on defined subset of data? Reference can be defined on column which has unique constraint. It is also possible to create partial unique index. So it should by possible to reference this column. But postgres can not see this constraint and raises: ERROR: there is no unique constraint matching given keys for referenced table Any ideas ??? I dont feel my self to rewrite builtin trigger function which ensures reference integrity. -- 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] Recursive plpgsql function in rule
mito wrote: I am trying to select subtree by parent id in table: create table categories( id int, parent_id int ); I am fetching it by recursive plpgsql function, which works well. When i use that function as part of rule operation, i am getting ERROR: stack depth limit exceeded. I have tried to rewrite without recursion which cause infinite loop in rule. Is it possible to sent dynamic structures in planer? Or how to fetch subtree without change of table structure inside rule? I didn't quite understand the issue, but as a general hint you might want to look at PG 8.4 beta which introduces support for recursive queries using the SQL standard WITH syntax. That's very useful when dealing with tree structures. -- 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
[HACKERS] planner crash/assert hit in 8.4B1
While playing with 8.4b1 against one of our production databases I quickly managed to run into the following assert: Program received signal SIGSEGV, Segmentation fault. 0x082d27ef in estimate_num_groups (root=0x8566398, groupExprs=0x85b9ed8, input_rows=1159344) at selfuncs.c:3071 3071Assert(rel-reloptkind == RELOPT_BASEREL); #0 0x082d27ef in estimate_num_groups (root=0x8566398, groupExprs=0x85b9ed8, input_rows=1159344) at selfuncs.c:3071 #1 0x08221b1c in create_unique_path (root=0x8566398, rel=0x85b746c, subpath=0x85b88bc, sjinfo=0x85b15cc) at pathnode.c:960 #2 0x08205484 in make_join_rel (root=0x8566398, rel1=0x85b0490, rel2=value optimized out) at joinrels.c:696 #3 0x082056fe in join_search_one_level (root=0x8566398, level=5, joinrels=0x85b225c) at joinrels.c:277 #4 0x081f86c3 in standard_join_search (root=0x8566398, levels_needed=5, initial_rels=0x85b21f0) at allpaths.c:899 #5 0x081f9a9b in make_rel_from_joinlist (root=0x8566398, joinlist=value optimized out) at allpaths.c:836 #6 0x081f9b6b in make_one_rel (root=0x8566398, joinlist=0x85b05f4) at allpaths.c:97 #7 0x0820e70f in query_planner (root=0x8566398, tlist=0x85ac6f4, tuple_fraction=0, limit_tuples=-1, cheapest_path=0xbfaac15c, sorted_path=0xbfaac158, num_groups=0xbfaac150) at planmain.c:252 #8 0x0820fc62 in grouping_planner (root=0x8566398, tuple_fraction=0) at planner.c:1007 #9 0x082119b0 in subquery_planner (glob=0x85a2c50, parse=0x856603c, parent_root=0x0, hasRecursion=0 '\0', tuple_fraction=0, subroot=0xbfaac2a8) at planner.c:482 #10 0x08211f1b in standard_planner (parse=0x856603c, cursorOptions=0, boundParams=0x0) at planner.c:191 #11 0x0826631f in pg_plan_query (querytree=0x856603c, cursorOptions=0, boundParams=0x0) at postgres.c:697 #12 0x08266423 in pg_plan_queries (querytrees=0x85a112c, cursorOptions=0, boundParams=0x0) at postgres.c:756 #13 0x08266cb2 in exec_simple_query (query_string=0x8565244 SELECT * FROM table5 WHERE t_id IN ( SELECT pl_value::integer FROM v_view1);) at postgres.c:920 #14 0x082684f6 in PostgresMain (argc=4, argv=0x850ffc8, username=0x850ff98 postgres) at postgres.c:3606 #15 0x08232ea1 in ServerLoop () at postmaster.c:3331 #16 0x08233c0c in PostmasterMain (argc=3, argv=0x84e11c8) at postmaster.c:1054 #17 0x081d6c97 in main (argc=3, argv=0x84e11c8) at main.c:188 A simple testcase to reproduce might be: CREATE TABLE table1 (p_id integer, pl_key text, pl_value text); CREATE TABLE table2 (p_id integer); CREATE TABLE table3 (sp_id integer, p_id integer, u_id integer); CREATE TABLE table4 (u_id integer); CREATE VIEW v_view1 AS SELECT sp.sp_id, u.u_id, pl.pl_key, CASE WHEN ((pl.pl_key)::text 'foobar'::text) THEN pl.pl_value WHEN (((pl.pl_key)::text = 'baz'::text) AND (u.u_id IN (SELECT sp.u_id FROM table3 sp, table2 p WHERE sp.p_id = p.p_id))) THEN pl.pl_value ELSE '0'::text END AS pl_value FROM table4 u, table3 sp, table2 p, table1 pl WHERE ((u.u_id = sp.u_id) AND (sp.p_id = p.p_id)) AND (p.p_id = pl.p_id); CREATE TABLE table5 (t_id integer); SELECT * FROM table5 WHERE t_id IN (SELECT pl_value::integer FROM v_view1); 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] Reference on partial data
mito wrote: Hi, is it possible to create reference constraint only on defined subset of data? Reference can be defined on column which has unique constraint. It is also possible to create partial unique index. So it should by possible to reference this column. But postgres can not see this constraint and raises: ERROR: there is no unique constraint matching given keys for referenced table Any ideas ??? I dont feel my self to rewrite builtin trigger function which ensures reference integrity. No, it's not. This looks like a usage question, which doesn't belong on -hackers. Please ask such questions on pgsql-general. 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] planner crash/assert hit in 8.4B1
--On Sonntag, April 19, 2009 15:29:01 +0200 Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: Program received signal SIGSEGV, Segmentation fault. 0x082d27ef in estimate_num_groups (root=0x8566398, groupExprs=0x85b9ed8, input_rows=1159344) at selfuncs.c:3071 3071Assert(rel-reloptkind == RELOPT_BASEREL); Please note that it doesn't raise the Assert, it crashes because rel is NULL, hence the assertion expression crashes with a SIGSEGV. There seems to be something wrong with the RelOptInfo in estimate_num_groups(). -- Thanks Bernd -- 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] unalias of ACL_SELECT_FOR_UPDATE
KaiGai Kohei kai...@kaigai.gr.jp writes: Heikki Linnakangas wrote: Why should it discriminate between them? Typically, we cannot set up a foreign-key which refers a primary-key within read-only table from SELinux's viewpoint. The vanilla access control mechanism switches the current userid, and it enables to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model does not have a concept of ownership. Should I not read that as SELinux's security model is so impoverished that it cannot be useful for monitoring SQL behavior? If you don't understand current user and ownership, it's hopeless. Trying to distinguish SELECT FOR UPDATE instead of that is a workaround that is only going to fix one symptom (if it even works for this, which I doubt). There will be many more. 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] to_timestamp() changes in 8.4 release notes
Brendan Jurd dire...@gmail.com writes:
I noticed the following item under Observe the following
incompatibilities in the 8.4 release notes (E.1.2.4.1.)
* Require to_timestamp() input to match meridian (AM/PM) and era
(BC/AD) format designations with respect to presence of periods
(Brendan Jurd)
For example, input value AD now does not match format string A.D..
This is actually not a change in behaviour.
Well, it does seem to have some visible effect --- in 8.3 I see
regression=# select to_timestamp('1BC', 'A.D.');
to_timestamp
0001-01-01 00:00:00-05
(1 row)
ie, failure to match means the field is silently ignored. In HEAD,
regression=# select to_timestamp('1BC', 'A.D.');
ERROR: invalid value BC for A.D.
DETAIL: The given value did not match any of the allowed values for this field.
ie, failure to match means you get an error.
I guess though your point is that this is part of the general tightening
of to_timestamp()'s error checking, and doesn't need a separate entry?
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] to_timestamp() changes in 8.4 release notes
On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane t...@sss.pgh.pa.us wrote: Well, it does seem to have some visible effect --- in 8.3 I see ... ie, failure to match means the field is silently ignored. In HEAD, ... ie, failure to match means you get an error. I guess though your point is that this is part of the general tightening of to_timestamp()'s error checking, and doesn't need a separate entry? You guess correctly =) There might be some value in changing the wording of that paragraph about the general tightening to emphasise that queries which previously succeeded (with some parts being misinterpreted or silently disregarded) will now throw an error. It is entirely possible that these changes will break existing queries, although I would like to hope that there aren't too many people out there relying on the quirky misbehaviours of to_timestamp(). To this item: Cause to_date() and to_timestamp() to more consistently report errors for invalid input (Brendan Jurd) We could add a line like: Some invalid inputs which were silently ignored or misread in 8.3 and earlier, will now cause an ERROR to be raised. 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] planner crash/assert hit in 8.4B1
Bernd Helmle maili...@oopsware.de writes: --On Sonntag, April 19, 2009 15:29:01 +0200 Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: Program received signal SIGSEGV, Segmentation fault. Please note that it doesn't raise the Assert, it crashes because rel is NULL, hence the assertion expression crashes with a SIGSEGV. There seems to be something wrong with the RelOptInfo in estimate_num_groups(). It looks like I neglected to test this code while writing the PlaceHolderVar patch --- it needs to handle those specially, and fails to do so :-(. Thanks for the report! 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] Unicode support
On Monday 13 April 2009 20:18:31 - - wrote: 1) Functions like char_length() or length() do NOT return the number of characters (the manual says they do), instead they return the number of code points. I have added a Todo item about possibly fixing this. -- 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] to_timestamp() changes in 8.4 release notes
Brendan Jurd dire...@gmail.com writes: On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane t...@sss.pgh.pa.us wrote: I guess though your point is that this is part of the general tightening of to_timestamp()'s error checking, and doesn't need a separate entry? You guess correctly =) There might be some value in changing the wording of that paragraph about the general tightening to emphasise that queries which previously succeeded (with some parts being misinterpreted or silently disregarded) will now throw an error. OK, done. I wrote Previous versions would often ignore or silently misread input that did not match the format string. Such cases will now result in an error. 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] Unicode support
Peter Eisentraut pete...@gmx.net writes: On Monday 13 April 2009 20:18:31 - - wrote: 1) Functions like char_length() or length() do NOT return the number of characters (the manual says they do), instead they return the number of code points. I have added a Todo item about possibly fixing this. I thought the conclusion of the thread was that this wasn't wrong? 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] Why isn't stats_temp_directory automatically created?
Fujii Masao wrote: Hi, Hi! Sorry about the very late response - I've been out of the country and generally busy. On Wed, Apr 15, 2009 at 5:37 PM, Magnus Hagander mag...@hagander.net wrote: This does not take into account the effect of symlinks as mentioned by Itakagi Takahiro. I haven't looked at the details, but I don't think it would be that much more work to deal with it - and as he mentions, this is a very common usecase. Okey, I'll revise the patch; create also the directory which is referenced by symlink if not present. Great. Also, wouldn't it be better to isolate this to the first time when we try to create the file - then we don't have to export the symbol? You mean having assign_pgstat_temp_directory() create the directory instead of pgstat_start()? In this case, the directory is created automatically not only at the beginning but also when a configuration file is reloaded. This seems to be better behavior. No, I meant creating it when we open the file - in pgstat_write_statsfile(). //Magnus -- 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] Replacing plpgsql's lexer
I wrote:
So I think we are down to a choice of doing nothing for 8.4, or teaching
the existing plpgsql lexer about standard_conforming_strings. Assuming
the current proposal for U literals holds up, it should not be
necessary for plpgsql to know about those explicitly as long as it obeys
standard_conforming_strings, so this might not be too horrid a project.
I'll take a look at that next.
The attached proposed patch rips out plpgsql's handling of comments and
string literals, and puts in scanner rules that are extracted from the
core lexer (but simplified in a few places where we don't need all the
complexity). The net user-visible effects should be:
* Both regular and E'' literals should now be parsed exactly the same
as the core does it.
* Nested slash-star comments are now handled properly.
* Warnings and errors associated with string parsing should now match
the core, which means they might vary a bit from previous plpgsql
behavior.
I need to test this a bit more, and it could probably do with adding
a few regression test cases, but I think it's code-complete.
Comments?
regards, tom lane
PS: in passing I got rid of the scanner_functype/scanner_typereported
kluge, which might once have had some purpose but now is just cluttering
both the scanner and the grammar. This is a leftover from my failed
attempt at removing the scanner altogether. Since it simplifies the
code I thought I'd keep it.
Index: src/pl/plpgsql/src/gram.y
===
RCS file: /cvsroot/pgsql/src/pl/plpgsql/src/gram.y,v
retrieving revision 1.121
diff -c -r1.121 gram.y
*** src/pl/plpgsql/src/gram.y 18 Feb 2009 11:33:04 - 1.121
--- src/pl/plpgsql/src/gram.y 19 Apr 2009 16:28:04 -
***
*** 62,67
--- 62,69
int lineno);
staticvoid check_sql_expr(const char *stmt);
staticvoid plpgsql_sql_error_callback(void *arg);
+ staticchar*parse_string_token(const char *token);
+ staticvoid plpgsql_string_error_callback(void
*arg);
staticchar*check_label(const char *yytxt);
staticvoid check_labels(const char *start_label,
const
char *end_label);
***
*** 228,235
/*
* Other tokens
*/
- %tokenT_FUNCTION
- %tokenT_TRIGGER
%tokenT_STRING
%tokenT_NUMBER
%tokenT_SCALAR/* a VAR, RECFIELD, or
TRIGARG */
--- 230,235
***
*** 244,256
%%
! pl_function : T_FUNCTION comp_optsect pl_block opt_semi
{
! yylval.program =
(PLpgSQL_stmt_block *)$3;
! }
! | T_TRIGGER comp_optsect pl_block opt_semi
! {
! yylval.program =
(PLpgSQL_stmt_block *)$3;
}
;
--- 244,252
%%
! pl_function : comp_optsect pl_block opt_semi
{
! yylval.program =
(PLpgSQL_stmt_block *) $2;
}
;
***
*** 1403,1409
if (tok == T_STRING)
{
/* old style
message and parameters */
! new-message =
plpgsql_get_string_value();
/*
* We expect
either a semi-colon, which
* indicates no
parameters, or a comma that
--- 1399,1405
if (tok == T_STRING)
{
/* old style
message and parameters */
! new-message =
parse_string_token(yytext);
/*
* We expect
either a semi-colon, which
* indicates no
parameters, or a comma
[HACKERS] Duplicate code in psql's \ commands
Folks, While working on the new improved \df, I noticed a pretty major infelicity, namely that \ commands get validated by two completely independent code paths, namely tab-complete.c and command.c/describe.c. I'm thinking it would be a good idea to factor the validating out as far as possible. This would also make it easier to make sure that tab completion and \'s output match to the maximal reasonable extent. Objections? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com 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] Replacing plpgsql's lexer
On Sun, Apr 19, 2009 at 5:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: * Nested slash-star comments are now handled properly. as opposed to? -- greg -- 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] Replacing plpgsql's lexer
On 19 Apr 2009, at 17:42, Tom Lane wrote: The attached proposed patch rips out plpgsql's handling of comments and string literals, and puts in scanner rules that are extracted from the core lexer (but simplified in a few places where we don't need all the complexity). The net user-visible effects should be: Comments? Will it also mean, that queries are going to be analyzed deeper ? Ie, afaik I am able now to create plpgsql function, that tries to run query accessing non existent table, or columns. Or, if I rename column/table/relation now, views, etc are getting updated - but not plpgsql functions. Will that change with your patch ? -- 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] Replacing plpgsql's lexer
On Sun, Apr 19, 2009 at 6:24 PM, Grzegorz Jaskiewicz g...@pointblue.com.pl wrote: Will it also mean, that queries are going to be analyzed deeper ? Ie, afaik I am able now to create plpgsql function, that tries to run query accessing non existent table, or columns. Or, if I rename column/table/relation now, views, etc are getting updated - but not plpgsql functions. Will that change with your patch ? The scanner isn't responsible for anything like this. It just braeks the input up into tokens. So its responsible for determining where strings start and end and where tble names start and end but doesn't actually look up the name anywhere -- that's up to the parser and later steps. So no. -- greg -- 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] Replacing plpgsql's lexer
On 19 Apr 2009, at 18:28, Greg Stark wrote: On Sun, Apr 19, 2009 at 6:24 PM, Grzegorz Jaskiewicz g...@pointblue.com.pl wrote: Will it also mean, that queries are going to be analyzed deeper ? Ie, afaik I am able now to create plpgsql function, that tries to run query accessing non existent table, or columns. Or, if I rename column/table/relation now, views, etc are getting updated - but not plpgsql functions. Will that change with your patch ? The scanner isn't responsible for anything like this. It just braeks the input up into tokens. So its responsible for determining where strings start and end and where tble names start and end but doesn't actually look up the name anywhere -- that's up to the parser and later steps. So no. ok, thanks. To be honest, That would be the great feature. -- 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] Replacing plpgsql's lexer
Greg Stark st...@enterprisedb.com writes: On Sun, Apr 19, 2009 at 5:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: * Nested slash-star comments are now handled properly. as opposed to? They nest, as required by the SQL spec and implemented by our core lexer. plpgsql didn't use to get this right. 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] to_timestamp() changes in 8.4 release notes
On Mon, Apr 20, 2009 at 1:51 AM, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: There might be some value in changing the wording of that paragraph about the general tightening ... OK, done. I wrote Previous versions would often ignore or silently misread input that did not match the format string. Such cases will now result in an error. Excellent, thanks Tom. 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] Patch for 8.5, transformationHook
On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote: There are lot of things, that should be done with current grammar only on transformation stage. Currently pg do it now. There are lot of pseudo functions, that are specially transformed: least, greatest, coalesce. After hooking we should do some similar work from outer libraries. There are surely other ways to accomplish this than an expression transformation hook. Adding a property or two to the function definition to do what you want could do 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] Patch for 8.5, transformationHook
2009/4/19 Peter Eisentraut pete...@gmx.net: On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote: There are lot of things, that should be done with current grammar only on transformation stage. Currently pg do it now. There are lot of pseudo functions, that are specially transformed: least, greatest, coalesce. After hooking we should do some similar work from outer libraries. There are surely other ways to accomplish this than an expression transformation hook. Adding a property or two to the function definition to do what you want could do it. should you describe it little bit more? 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] Duplicate code in psql's \ commands
David Fetter da...@fetter.org writes: While working on the new improved \df, I noticed a pretty major infelicity, namely that \ commands get validated by two completely independent code paths, namely tab-complete.c and command.c/describe.c. Why is tab-complete doing anything that could be described as validation? I'm thinking it would be a good idea to factor the validating out as far as possible. This would also make it easier to make sure that tab completion and \'s output match to the maximal reasonable extent. I rather doubt that this will really be much of a win, but if you want to try it as a separate patch, go ahead. 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] Duplicate code in psql's \ commands
On Sun, Apr 19, 2009 at 02:09:48PM -0400, Tom Lane wrote: David Fetter da...@fetter.org writes: While working on the new improved \df, I noticed a pretty major infelicity, namely that \ commands get validated by two completely independent code paths, namely tab-complete.c and command.c/describe.c. Why is tab-complete doing anything that could be described as validation? Using fixed-string comparisons--and this is already not quite right for cases like \dvi--tab-complete can tell which command it's going to complete. That's validation as far as it goes, but what it means is that while \d [tab] works (kinda), things like \dS [tab] don't. I'm thinking it would be a good idea to factor the validating out as far as possible. This would also make it easier to make sure that tab completion and \'s output match to the maximal reasonable extent. I rather doubt that this will really be much of a win, but if you want to try it as a separate patch, go ahead. OK :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com 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
[HACKERS] Sigh, MSVC build broken again
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2009-04-19%2019:00:00 It looks like the MSVC build scripts are cheating by not copying parser/gram.h into the include tree where it should be. I'm not entirely sure why that has worked at all in the past, but it's not working any more. 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] [rfc] unicode escapes for extended strings
Marko Kreen mark...@gmail.com writes: On 4/18/09, Tom Lane t...@sss.pgh.pa.us wrote: The point has come up before, and I kinda thought we *had* changed the lexer to reject \000. I see we haven't though. Curiously, this does fail: regression=# select U'abc\xyz'; ERROR: invalid byte sequence for encoding SQL_ASCII: 0x00 I think that's because out verifier actually *does* reject \0, only problem is that \0 does not set saw_high_bit flag, so the verifier simply does not get executed. But U executes it always. I fixed this in HEAD. 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] Sigh, MSVC build broken again
I wrote: It looks like the MSVC build scripts are cheating by not copying parser/gram.h into the include tree where it should be. I'm not entirely sure why that has worked at all in the past, but it's not working any more. On further consideration, it's probably not a good idea to let plpgsql depend on gram.h anyway --- in the past we've taken measures to confine the use of that file as narrowly as possible. I did a bit of code refactoring 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] [PATCH] Borland C Compiler compatibility issues
Pavel Golub pa...@microolap.com writes: Here the patch to /src/include/pg_config_os.h attached improving Borland C++ Compiler compatibility. Applied along with your other two patches. Please note in future that pg_config_os.h is a derived file --- this patch should have been against src/include/port/win32.h. 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] unalias of ACL_SELECT_FOR_UPDATE
Tom Lane wrote: KaiGai Kohei kai...@kaigai.gr.jp writes: Heikki Linnakangas wrote: Why should it discriminate between them? Typically, we cannot set up a foreign-key which refers a primary-key within read-only table from SELinux's viewpoint. The vanilla access control mechanism switches the current userid, and it enables to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model does not have a concept of ownership. Should I not read that as SELinux's security model is so impoverished that it cannot be useful for monitoring SQL behavior? If you don't understand current user and ownership, it's hopeless. Trying to distinguish SELECT FOR UPDATE instead of that is a workaround that is only going to fix one symptom (if it even works for this, which I doubt). There will be many more. It is a difference between two security designs, characteristics and philosophies, not a competitive merit and demerit. SELinux makes its decision based on the security policy and the security context of client and objects accessed. Here, user identifier and object ownership don't appear. Meanwhile, the vanilla PostgreSQL makes its decision based on the user identifier and database ACLs of objects accessed. It does not use the security context, needless to say. At the begining, I considered that SE-PostgreSQL want ACL_SELECT_FOR_UPDATE to have individual bit other than ACL_UPDATE, but I also considered it should not add user visible changes in the vanilla access controls, so the first proposition changed only internal representation without new user visible permissions (it was still checked as UPDATE privilege). Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] WITH inconsistency
Hi, I found some inconsistency on WITH keyword: 1) = \h CREATE TABLE [...] [ WITH ( storage_parameter [= value] [, ... ] ) ] [...] = is required 2) = \h CREATE ROLE Command: CREATE ROLE Description: define a new database role Syntax: CREATE ROLE name [ [ WITH ] option [ ... ] ] where option can be: SUPERUSER | NOSUPERUSER [...] | IN ROLE rolename [, ...] | IN GROUP rolename [, ...] | ROLE rolename [, ...] | ADMIN rolename [, ...] | USER rolename [, ...] | SYSID uid = is not available 3) = \h CREATE DATABASE Command: CREATE DATABASE Description: create a new database Syntax: CREATE DATABASE name [ [ WITH ] [ OWNER [=] dbowner ] [ TEMPLATE [=] template ] [ ENCODING [=] encoding ] [ LC_COLLATE [=] lc_collate ] [ LC_CTYPE [=] lc_ctype ] [ TABLESPACE [=] tablespace ] [ CONNECTION LIMIT [=] connlimit ] ] = is optional Cheers, Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
