On Tue, 24 Apr 2007, Bruce Momjian wrote:
> Naz Gassiep wrote:
> > A few of us on IRC were wondering what the status of tsearch2 is in 8.3 ?
> > Was it decided to include it in core or did we decide to keep FTS as a
> > plugin?
> > Some brief comments from anyone on the inside of the whole FTS iss
Tom Lane wrote:
"Robert Haas" <[EMAIL PROTECTED]> writes:
...
IF this will be implemented as suggested here, it will become
extremely counter-intuitive.
...
You could solve this by having explicit positive and negative ACLs, i.e.
your permissions for a particular column are:
"Robert Haas" <[EMAIL PROTECTED]> writes:
...
>> IF this will be implemented as suggested here, it will become
>> extremely counter-intuitive.
...
> You could solve this by having explicit positive and negative ACLs, i.e.
> your permissions for a particular column are:
Uh, wait a moment, people.
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Tue, 24 Apr 2007, Ned T. Crigler wrote:
>> The JDBC driver does not connect successfully to a CVS HEAD server
>> (updated as of today) when using a database set to UTF8 encoding;
> Indeed, referring to -hackers as this is a recent backend change. The
>
I think there are two basically orthogonal features in the patch: the
"RETURNS TABLE" addition to CREATE FUNCTION, and the "RETURN TABLE"
statement in PL/PgSQL. The former is specified by the SQL standard and
is applicable to all PLs, while the latter is syntax sugar for PL/PgSQL.
I think it would
two of my buildfarm members had different but pretty weird looking
failures lately:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:03:03
and
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emu&dt=2007-04-24%2014:35:02
any ideas on what might causing those ?
Ste
Robert Haas wrote:
My strongly opinion is that, REVOKE column-level priviledge should
revoke access to that column, in effect it should reduce the table-level
grant to column-level grants.
I think this causes problems when columns are added to the table. If
table X has columns A, B, C, an
Dear August
Thank you for your reply.
On 4/25/07, August Zajonc <[EMAIL PROTECTED]> wrote:
Golden Liu wrote:
> 3. Before evaluating a SQL command, check column-level privilege.
> This is done AFTER checking table-level privilege. As I mentioned
> before, if table-level privilege is granted, it'
On Tuesday 24 April 2007 17:38, Neil Conway wrote:
> [ CC'ing -hackers ]
>
> On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote:
> > This patch adds a sentence on monitoring.sgml explaining that
> > stats_row_level needs to be enabled if user wants to get last
> > vacuum/analyze execution t
> >It sounds like table || column is the check, so table implies
> >all of columns. ie, revoking a column permission does nothing
> >unless TABLE permission is also revoked.
>
> IF this will be implemented as suggested here, it will become
extremely
> counter-intuitive. Its just like you have ac
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of August Zajonc
>Sent: dinsdag 24 april 2007 18:34
>To: Golden Liu
>Cc: pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Google SoC: column-level privilege subsystem
>
>Golden Liu wrote:
>> 3. Before eva
On Tue, 24 Apr 2007, Ned T. Crigler wrote:
The JDBC driver does not connect successfully to a CVS HEAD server
(updated as of today) when using a database set to UTF8 encoding;
enabling the debug messages in the driver shows that it is sending
client_encoding=UNICODE in the startup packet, but
[ CC'ing -hackers ]
On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote:
> This patch adds a sentence on monitoring.sgml explaining that
> stats_row_level needs to be enabled if user wants to get last
> vacuum/analyze execution time.
This behavior was introduced in r1.120 of postmaster/p
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The pending-fsync stuff in md.c is also expecting to be able to add
>> entries during a scan.
> No, mdsync starts the scan from scratch after calling AbsorbFsyncRequests.
That was last month ;-). It doesn't restart any more.
>
Tom Lane wrote:
The pending-fsync stuff in md.c is also expecting to be able to add
entries during a scan.
No, mdsync starts the scan from scratch after calling AbsorbFsyncRequests.
I don't think we can go in the direction of forbidding insertions during
a scan --- as the case at hand shows,
Josh Berkus wrote:
> Bruce, All,
>
> (x-posting to Advocacy, hopefully to forestall flames)
>
> > I want to apologize for having my signature at the bottom of the 8.2.4,
> > etc. release announcement. There is no reason to mention my name,
> > company, and web site at the bottom of something tha
Bruce, All,
(x-posting to Advocacy, hopefully to forestall flames)
> I want to apologize for having my signature at the bottom of the 8.2.4,
> etc. release announcement. There is no reason to mention my name,
> company, and web site at the bottom of something that is supposed to
> come from the
On Tue, 2007-04-24 at 07:58 +0200, Pavel Stehule wrote:
> It is RETURN TABLE(SQL) via ANSI SQL 2003
I think there are two basically orthogonal features in the patch: the
"RETURNS TABLE" addition to CREATE FUNCTION, and the "RETURN TABLE"
statement in PL/PgSQL. The former is specified by the SQL st
Am Dienstag, 24. April 2007 19:48 schrieb Tom Lane:
> You're missing the point, which is that the inner UNION needs to decide
> what its uniqueness semantics are, independently of what might happen to
> its result later. Or that's how I read the spec anyway.
It's probably safer to leave it as is.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
>> Does it even matter except in the case of nulls? I mean, if the inner pair
>> uses integer and then the outer pair uses bigint it'll still work correctly,
>> no?
>
> Oh, it absolutely matters: you can get diffe
Josh Berkus <[EMAIL PROTECTED]> writes:
> Well, as a PG hacker I find the name wal_fullpage_optimization quite
> baffling and I think our general user base will find it even more so.
> Now that I have Koichi's explanation of the problem, I vote for simply
> slaving this to the PITR settings and not
Koichi, Andreas,
> 1) To deal with partial/inconsisitent write to the data file at crash
> recovery, we need full page writes at the first modification to pages
> after each checkpoint. It consumes much of WAL space.
We need to find a way around this someday. Other DBs don't do this; it may be
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Maybe we should just ignore those qualms and do it anyway --- I must
>> admit that I'm hard-pressed to come up with a situation where anyone
>> would really want different datatypes used in the inner union than
>>
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Maybe we should just ignore those qualms and do it anyway --- I must
> admit that I'm hard-pressed to come up with a situation where anyone
> would really want different datatypes used in the inner union than
> the outer.
Does it even matter except in the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The resolution to my problem with the select_common_type() error message
> turned out to be that this doesn't work:
> postgres=# select null union select null union select 1;
> ERROR: UNION types text and integer cannot be matched
Yeah, this has be
Am Dienstag, 24. April 2007 14:54 schrieb Golden Liu:
> Here is a plan of my project:
All of that should be pretty straightforward. But have you given any thoughts
to how you want to represent the column privileges in the parse tree and how
you want to process them in the rewriter? That will b
The resolution to my problem with the select_common_type() error message
turned out to be that this doesn't work:
postgres=# select null union select null union select 1;
ERROR: UNION types text and integer cannot be matched
That's because it resolves the first two branches independently, then
Golden Liu wrote:
3. Before evaluating a SQL command, check column-level privilege.
This is done AFTER checking table-level privilege. As I mentioned
before, if table-level privilege is granted, it's not necessary to
check column-level privilege.
Golden, this sounds good. I'm just a user.
It s
In the modified version of ECPG that we used for our benchmark, we
PREPARE'd all statements.
-Original Message-
From: Michael Meskes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 12:45 AM
To: William Lawrance
Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I briefly went through all callers of hash_seq_init. The only place
> where we explicitly rely on being able to add entries to a hash table
> while scanning it is in tbm_lossify. There's more complex loops in
> portalmem.c and relcache.c, which I
On 4/23/07, Neil Conway <[EMAIL PROTECTED]> wrote:
On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
> Attached patch does following conversions:
ISTM it would be cleaner to use an enum to identify the different
variants of the DISCARD command, rather than a character string.
Is guc.c still
Naz Gassiep wrote:
> A few of us on IRC were wondering what the status of tsearch2 is in 8.3 ?
> Was it decided to include it in core or did we decide to keep FTS as a
> plugin?
> Some brief comments from anyone on the inside of the whole FTS issue
> would be greatly appreciated by us mere end us
Bruce Momjian wrote:
I want to apologize for having my signature at the bottom of the 8.2.4,
etc. release announcement. There is no reason to mention my name,
company, and web site at the bottom of something that is supposed to
come from the community. And I didn't even write that email --- I w
I want to apologize for having my signature at the bottom of the 8.2.4,
etc. release announcement. There is no reason to mention my name,
company, and web site at the bottom of something that is supposed to
come from the community. And I didn't even write that email --- I was
doing it for someone
Magnus Hagander wrote:
On Tue, Apr 24, 2007 at 09:18:54AM -0400, Robert Treat wrote:
On Tuesday 24 April 2007 01:32, Magnus Hagander wrote:
That would be just because you don't know the numbering scheme. 8.2 to
8.3 is considered "major" in these parts. See
http://www.postgresql.org/su
Michael Meskes wrote:
> On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> > Our first attempt to use the ECPG prepare interface revealed that ECPG
> > doesn't use the PQlib prepare function. The ECPG prepare replaces any
> > parameters with their values and presents a new SQL stat
On Tue, Apr 24, 2007 at 09:18:54AM -0400, Robert Treat wrote:
> On Tuesday 24 April 2007 01:32, Magnus Hagander wrote:
> > > > That would be just because you don't know the numbering scheme. 8.2 to
> > > > 8.3 is considered "major" in these parts. See
> > > > http://www.postgresql.org/support/ver
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The main data from the statistics that's of interest here are the extreme
>> values of the histogram. If we're not interested in any values in that range
>> then we can exclude the partition entirely.
>
> Except
On Tuesday 24 April 2007 01:32, Magnus Hagander wrote:
> > > That would be just because you don't know the numbering scheme. 8.2 to
> > > 8.3 is considered "major" in these parts. See
> > > http://www.postgresql.org/support/versioning
> >
> > Is that official policy? I don't see any mention of it
Hi all,
I'm one of the Google SoC's students for PostgreSQL. My project is
to implement column-level privilege in PG. Here is a description of my
project. Any and all help and/or comment is appreciated.
Table-level privilege subsystem in PG is now used like this:
GRANT { { SELECT | INSERT | UPDA
Heikki Linnakangas wrote:
Tom Lane wrote:
Also, we have a generic issue that making fresh entries in a hashtable
might result in a concurrent hash_seq_search scan visiting existing
entries more than once; that's definitely not something any of the
existing callers are thinking about.
Ouch. Not
On 4/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Oh, you're talking about distributing partitions across different nodes
and parallelizing queries. No, we don't do that today.
PL/Proxy actually works like that, only in smaller scope -
for function calls only.
General solution that par
A few of us on IRC were wondering what the status of tsearch2 is in 8.3 ?
Was it decided to include it in core or did we decide to keep FTS as a
plugin?
Some brief comments from anyone on the inside of the whole FTS issue
would be greatly appreciated by us mere end users.
Regards,
- Naz.
-
> 3) To maintain crash recovery chance and reduce the amount of
> archive log, removal of unnecessary full page writes from
> archive logs is a good choice.
Definitely, yes. pg_compresslog could even move the full pages written
during backup out of WAL and put them in a different file that nee
On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> Our first attempt to use the ECPG prepare interface revealed that ECPG
> doesn't use the PQlib prepare function. The ECPG prepare replaces any
> parameters with their values and presents a new SQL statement to the
This is true and
45 matches
Mail list logo
