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 [ ... ] ]
w
Tom Lane wrote:
> KaiGai Kohei 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 curre
Pavel Golub 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.
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
plp
Marko Kreen writes:
> On 4/18/09, Tom Lane 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 "
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=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.
On Sun, Apr 19, 2009 at 02:09:48PM -0400, Tom Lane wrote:
> David Fetter 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
David Fetter 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 val
2009/4/19 Peter Eisentraut :
> 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,
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 shou
On Mon, Apr 20, 2009 at 1:51 AM, Tom Lane wrote:
> Brendan Jurd 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 n
Greg Stark writes:
> On Sun, Apr 19, 2009 at 5:42 PM, Tom Lane 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
On 19 Apr 2009, at 18:28, Greg Stark wrote:
On Sun, Apr 19, 2009 at 6:24 PM, Grzegorz Jaskiewicz
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
On Sun, Apr 19, 2009 at 6:24 PM, Grzegorz Jaskiewicz
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, vie
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 e
On Sun, Apr 19, 2009 at 5:42 PM, Tom Lane 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
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.
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
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 wrote:
>> This does not take into account the effect of symlinks as mentioned by
>> Itakagi Takahiro. I haven't looked at the
Peter Eisentraut 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 th
Brendan Jurd writes:
> On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane 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 word
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 l
Bernd Helmle writes:
> --On Sonntag, April 19, 2009 15:29:01 +0200 Stefan Kaltenbrunner
> 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. Ther
On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane 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
Brendan Jurd 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)
>
KaiGai Kohei 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
> enab
--On Sonntag, April 19, 2009 15:29:01 +0200 Stefan Kaltenbrunner
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_
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
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:
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 and
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
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
--
Sen
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 goi
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
35 matches
Mail list logo
