On Jul 12, 2008, at 14:50, David E. Wheeler wrote:
* An explicit comment explaining that you're piggybacking on the I/O
functions (and some others) for "text" wouldn't be out of place.
I've added SQL comments. Were you talking about a COMMENT?
* Lose the GRANT EXECUTEs on the I/O functions;
On Jul 12, 2008, at 15:13, David E. Wheeler wrote:
Sadly, I think you have to give up
attempts to check the interesting multibyte cases and confine
yourself
to tests using ASCII strings.
Grr. Kind of defeats the purpose. Is there no infrastructure for
testing multibyte functionality? Are
On Jul 12, 2008, at 14:57, Tom Lane wrote:
There was some discussion earlier about whether the proposed
regression
tests for citext are suitable for use in contrib or not. After
playing
with them for awhile, I have to come down very firmly on the side of
"not". I have these gripes:
You'r
There was some discussion earlier about whether the proposed regression
tests for citext are suitable for use in contrib or not. After playing
with them for awhile, I have to come down very firmly on the side of
"not". I have these gripes:
1. The style is gratuitously different from every other
On Jul 12, 2008, at 12:17, Tom Lane wrote:
BTW, I looked at the SQL file (citext.sql.in) a bit. Some comments:
Thanks a million for these, Tom. I greatly appreciate it.
* An explicit comment explaining that you're piggybacking on the I/O
functions (and some others) for "text" wouldn't be ou
OK, here's the (hopefully final) version of the typanalyze function for
tsvectors. It applies to HEAD and passes regression tests.
I now plan to move towards a selectivity function that'll use the
gathered statistics.
Thanks to everyone for their reviews and comments,
Cheers,
Jan
--
Jan Urb
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> But I notice that nobody else has commented on whether they want this
> feature or not. Does anyone particularly dislike the idea?
I think it's probably reasonable as long as we keep the implicitly
granted rights as narrow as possible. INSERT on the
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> + if (istmt.all_privs)
> + istmt_seq.all_privs = true;
> + else
> + {
> + if (istmt.privileges & ACL_INSERT)
> + istmt_seq.privileges |= ACL_USAGE;
At 2008-07-12 14:32:03 -0500, [EMAIL PROTECTED] wrote:
>
> > Should be "Granting permissions on a table automatically extends
> > those permissions to...".
>
> what about "extends them to..."
Yes, sounds fine, thanks.
But I notice that nobody else has commented on whether they want this
feature
On Sat, Jul 12, 2008 at 6:30 AM, Abhijit Menon-Sen <[EMAIL PROTECTED]> wrote:
>
>>
>> ! Granting permission on a table automatically extend
>> ! permissions to any sequences owned by the table, including
>> ! sequences tied to SERIAL columns.
>>
>
> Should be "Granting permi
BTW, I looked at the SQL file (citext.sql.in) a bit. Some comments:
* An explicit comment explaining that you're piggybacking on the I/O
functions (and some others) for "text" wouldn't be out of place.
* Lose the GRANT EXECUTEs on the I/O functions; they're redundant.
(If you needed them, you'd
Simon Riggs <[EMAIL PROTECTED]> writes:
> Yeh, I read that and thought something similar. But we're talking about
> temp additions to catalog tables, not all temp tables. If we tried to
> implement spec-compliant temp tables we would need to write to catalog
> tables again, which is what we are try
On Sat, 2008-07-12 at 12:04 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Seems like it would be a fairly big patch. The temp-bootstrap process is
> > still just hand-waving though.
>
> Yeah, and it seems fairly messy. The idea I'd had was that all the
> catalog entries fo
Simon Riggs <[EMAIL PROTECTED]> writes:
> Seems like it would be a fairly big patch. The temp-bootstrap process is
> still just hand-waving though.
Yeah, and it seems fairly messy. The idea I'd had was that all the
catalog entries for (a single set of) inheritance child tables are Just
There in t
On Sat, 2008-07-12 at 09:56 +0100, Dave Page wrote:
> An inheritance schema for pg_class may well work for them.
OK, proposal is something like this:
We must avoid writes to many system tables to allow temp tables to
function.
Priority 1
pg_class - base definition of table
pg_attribute - columns
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> At 2008-07-12 00:52:42 +0100, [EMAIL PROTECTED] wrote:
>> There was some discussion about this change and in fact if you
>> look at CVS HEAD you'll find it already applied.
> Not as far as I can see.
The place where it matters is in ExecIndexAdvance
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I think if we support UTF8 encoding, than it make sense to create own
> charsets,
> because system locales could have defined collation for that.
Say what? I cannot imagine a scenario in which a user-defined encoding
would be useful. The amount of inf
On Sat, Jul 12, 2008 at 10:02:24AM +0200, Zdenek Kotala wrote:
> Background:
> We specify encoding in initdb phase. ANSI specify repertoire, charset,
> encoding and collation. If I understand it correctly, then charset is
> subset of repertoire and specify list of allowed characters for
> langua
At 2008-07-12 00:52:42 +0100, [EMAIL PROTECTED] wrote:
>
> There was some discussion about this change and in fact if you
> look at CVS HEAD you'll find it already applied.
Not as far as I can see.
> Incrementing the most significant index keys would maximize the
> distance we're jumpin around in
At 2008-07-11 11:57:37 -0500, [EMAIL PROTECTED] wrote:
>
> attached is a new version of the patch, it implements Alvaro's
> suggestion and fix a bug i found (it wasn't managing GRANT ALL) :(
Looks good to me.
> About the SELECT issue, AFAIU Robert doesn't complaint he just asked
> what is the use
[EMAIL PROTECTED] ("Marko Kreen") writes:
> Also the design should be based on assumption that the target side
> is exactly in sync. Eg. DROP CASCADE should be replicated as DROP CASCADE.
> We should not make scheme more complex to survive cases where target
> is not in sync. That way madness lie
On Sat, Jul 12, 2008 at 9:16 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> So are you saying
>
> a) that other sessions need to be able to see pg_class entries for
> temporary tables created by different sessions?
>
> b) that you need to be able to see pg_class entries for temporary tables
> creat
On Sat, 2008-07-12 at 00:57 +0100, Dave Page wrote:
> On Sat, Jul 12, 2008 at 12:41 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote:
> >> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> > So it would seem that we need a way of handling temp tables
Alvaro Herrera napsal(a):
Zdenek Kotala escribió:
The example is when you have translation data (vocabulary) in database.
But the reason is that ANSI specify (chapter 4.2) charset as a part of
string descriptor. See below:
— The length or maximum length in characters of the character string
24 matches
Mail list logo
