KaiGai Kohei wrote:
> We have an another approach that defines ACL_SELECT_FOR_SHARE as
> an alias of ACL_SELECT, and applies it on SELECT FOR SHARE statement.
> (Needless to say, the targets are already listed, so it might not necessary
> to put a ACL_SELECT_FOR_SHARE bit explicitly.)
That's even
KaiGai Kohei wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> >> Kohei-san, what URL do you want me to list in the 8.4 release notes for
> >> the SE-Linux patches?
>
> If desirable, I'll prepare a wiki entry to point the list of patches
> and introduce the way to set up SE-PostgreSQL on the v
Tom Lane wrote:
> Bruce Momjian writes:
> > Kohei-san, what URL do you want me to list in the 8.4 release notes for
> > the SE-Linux patches?
>
> What? Why would there be anything in the 8.4 release notes about
> SEPostgres?
I suggested it here and no one objected:
http://archives.pos
Tom Lane wrote:
> KaiGai Kohei writes:
>> Heikki Linnakangas wrote:
>>> What's the point of doing SELECT FOR UPDATE if you're not actually going
>>> to UPDATE the row? Having separate permissions for SELECT FOR UPDATE and
>>> UPDATE seems useless.
>
>> I wonder why SELECT FOR UPDATE need ACL_UPDA
Tom Lane wrote:
> Bruce Momjian writes:
>> Kohei-san, what URL do you want me to list in the 8.4 release notes for
>> the SE-Linux patches?
If desirable, I'll prepare a wiki entry to point the list of patches
and introduce the way to set up SE-PostgreSQL on the v8.4 due to the
stable release.
>
Btw, There was a "EXPLAIN XML" summer of code project, wasn't there ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
> The lexer is *not* allowed to invoke any database operations
> (such as pg_conversion lookups)
I certainly hope it's not!
> so it cannot perform arbitrary encoding conversions.
I was more questioning whether we should be looking at character
encodings at all at that point
On 4/18/09, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Andrew Dunstan wrote:
> >> ISTM that one of the uses of this is to say "store the character
> >> that corresponds to this Unicode code point in whatever the database
> >> encoding is"
>
> > I would think you're right. As long as th
Sam Mason writes:
> On Fri, Apr 17, 2009 at 07:01:47PM +0200, Martijn van Oosterhout wrote:
>> On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
>>> Btw, is there any good reason why we don't reject \000, \x00
>>> in text strings?
>>
>> Why forbid nulls in text strings?
> As far as I
"Kevin Grittner" writes:
> Andrew Dunstan wrote:
>> ISTM that one of the uses of this is to say "store the character
>> that corresponds to this Unicode code point in whatever the database
>> encoding is"
> I would think you're right. As long as the given character is in the
> user's character
On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > Is this any better?
>
> So what happens if I do \dfaQ? It should throw an error, yes?
Interesting question.
>
> This help line:
>
> > + fprintf(output, _(" \\df[S+] [PATTERN] list functions. A
Marko Kreen wrote:
On 4/17/09, Kevin Grittner wrote:
Andrew Dunstan wrote:
> ISTM that one of the uses of this is to say "store the character
> that corresponds to this Unicode code point in whatever the database
> encoding is"
I would think you're right. As long as the given charact
On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > Is this any better?
>
> So what happens if I do \dfaQ? It should throw an error, yes?
>
> This help line:
>
> > + fprintf(output, _(" \\df[S+] [PATTERN] list functions. Add a, n,
> > t, w for
David Fetter wrote:
> Is this any better?
So what happens if I do \dfaQ? It should throw an error, yes?
This help line:
> + fprintf(output, _(" \\df[S+] [PATTERN] list functions. Add a, n,
> t, w for aggregate, normal, trigger, window\n"));
needs shortening to below 80 chars (or m
On 4/17/09, Kevin Grittner wrote:
> Andrew Dunstan wrote:
> > ISTM that one of the uses of this is to say "store the character
> > that corresponds to this Unicode code point in whatever the database
> > encoding is"
>
> I would think you're right. As long as the given character is in the
>
Andrew Dunstan wrote:
> ISTM that one of the uses of this is to say "store the character
> that corresponds to this Unicode code point in whatever the database
> encoding is"
I would think you're right. As long as the given character is in the
user's character set, we should allow it. Presum
Marko Kreen wrote:
+ if (c > 0x7F)
+ {
+ if (GetDatabaseEncoding() != PG_UTF8)
+ yyerror("Unicode escape values cannot be used for code point
values above 007F when the server encoding is not UTF8");
+ saw_high_bit = true;
+ }
David Fetter writes:
>> It's hardly a "show stopping bug", considering it's been there since
>> standard_conforming_strings was invented.
> A known sploit would be a show-stopper.
We're not turning on standard_conforming_strings right now. We are
*certainly* not forcing it on without recourse i
On Fri, Apr 17, 2009 at 02:07:55PM -0400, Tom Lane wrote:
> David Fetter writes:
> > Depends. If we've found show-stopping bugs, as it appears we may
> > have done, in not requiring standards_conforming_strings, we can't
> > just pull a MySQL and ship anyhow.
>
> It's hardly a "show stopping bug
On Fri, Apr 17, 2009 at 02:03:45PM -0400, Andrew Dunstan wrote:
> Alvaro Herrera wrote:
>> David Fetter wrote:
>>
>>> Speaking of standard_conforming_strings, I know it's late, but if
>>> we make it a requirement now, a lot of problems just go away.
>>> Yes, it's inconvenient, but we're making l
David Fetter writes:
> Depends. If we've found show-stopping bugs, as it appears we may have
> done, in not requiring standards_conforming_strings, we can't just
> pull a MySQL and ship anyhow.
It's hardly a "show stopping bug", considering it's been there since
standard_conforming_strings was i
Alvaro Herrera wrote:
David Fetter wrote:
Speaking of standard_conforming_strings, I know it's late, but if we
make it a requirement now, a lot of problems just go away. Yes, it's
inconvenient, but we're making lots of big changes, so one more
shouldn't halt adoption.
16 days too l
On Fri, Apr 17, 2009 at 07:01:47PM +0200, Martijn van Oosterhout wrote:
> On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
> > Btw, is there any good reason why we don't reject \000, \x00
> > in text strings?
>
> Why forbid nulls in text strings?
As far as I know, PG assumes, like mos
On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
> Btw, is there any good reason why we don't reject \000, \x00
> in text strings?
Why forbid nulls in text strings?
Have a nice day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> Please line up in a tree and maintain the h
On Fri, Apr 17, 2009 at 01:01:39PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > Speaking of standard_conforming_strings, I know it's late, but if
> > we make it a requirement now, a lot of problems just go away.
> > Yes, it's inconvenient, but we're making lots of big changes, so
> > o
David Fetter wrote:
> Speaking of standard_conforming_strings, I know it's late, but if we
> make it a requirement now, a lot of problems just go away. Yes, it's
> inconvenient, but we're making lots of big changes, so one more
> shouldn't halt adoption.
16 days too late ...
--
Alvaro Herrera
On Fri, Apr 17, 2009 at 12:12:12PM -0400, Tom Lane wrote:
> I wrote:
> > I had earlier speculated semi-facetiously about ripping out the
> > plpgsql lexer altogether, but the more I think about it the less
> > silly the idea looks.
>
> This little project crashed and burned upon remembering that p
This question is not appropriate for pgsql-hackers. You might try
pgsql-general or pgsql-novice.
Anyhow, it's just:
SELECT * FROM pg_class WHERE oid = 1247;
...Robert
2009/4/17 Alberto J. Castiñeira P. :
> Hi.
> I'll like to know how to use the "oid" in a where clause expressing the
> value in
Hi.
I'll like to know how to use the "oid" in a where clause expressing the
value in form of string or number.
many thanks.
--
atte: Alberto J. Castiñeira P.
AJCP
I wrote:
> I had earlier speculated semi-facetiously about ripping out the plpgsql
> lexer altogether, but the more I think about it the less silly the idea
> looks.
This little project crashed and burned upon remembering that plpgsql
invokes raw_parser() to syntax-check each chunk of SQL that it
On 4/16/09, Marko Kreen wrote:
> It's up to UTF8 validator whether to consider non-characters as error.
I checked, and it did not work well, as addunicode() did not set
the saw_high_bit variable.when outputting UTF8. Attached patch fixes it.
Currently is would be NOP as pg_verifymbstr() only ch
Hi.
I'll like to know how to use the "oid" in a where clause expressing the
value in form of string or number.
many thanks.
--
atte: Alberto J. Castiñeira P.
AJCP
--
atte: Alberto J. Castiñeira P.
AJCP
On Fri, Apr 17, 2009 at 10:15:57AM -0400, Tom Lane wrote:
> Sam Mason writes:
> > Just noticed that the spec only supports four hex digits;
>
> Better read it again.
You're right of course. My ability to read patches seems not to be very
good.
--
Sam http://samason.me.uk/
--
Sent via pgs
Sam Mason writes:
> Just noticed that the spec only supports four hex digits;
Better read it again.
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-hac
Bruce Momjian writes:
> Kohei-san, what URL do you want me to list in the 8.4 release notes for
> the SE-Linux patches?
What? Why would there be anything in the 8.4 release notes about
SEPostgres?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
KaiGai Kohei writes:
> Heikki Linnakangas wrote:
>> What's the point of doing SELECT FOR UPDATE if you're not actually going
>> to UPDATE the row? Having separate permissions for SELECT FOR UPDATE and
>> UPDATE seems useless.
> I wonder why SELECT FOR UPDATE need ACL_UPDATE, although the statemen
On Thu, Apr 16, 2009 at 12:08:37PM -0400, Tom Lane wrote:
> Sam Mason writes:
> > I've failed to keep up with the discussion so I'm not sure where this
> > conversation has got to! Is the consensus for 8.4 to enable SQL2003
> > style U&lit escaped literals if and only if standard_conforming_strin
Kohei-san, what URL do you want me to list in the 8.4 release notes for
the SE-Linux patches?
---
KaiGai Kohei wrote:
> The following list of patches are the latest SE-PostgreSQL (r1819).
>
> http://sepgsql.googlecode.com/f
38 matches
Mail list logo
