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
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
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
--
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
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
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.
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
3071
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
--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
3071
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,
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
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
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
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
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
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
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
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
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.
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:
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
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
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
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.
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
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
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,
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
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
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.
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
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
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
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
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 [ ... ] ]
35 matches
Mail list logo
