--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Fetter wrote:
> On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > Here is the patches he made against CVS HEAD (as of today).
>
> The git repository should now match this :)
>
> http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary
>
> Apparently, it's easiest
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> Here is the patches he made against CVS HEAD (as of today).
The git repository should now match this :)
http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary
Apparently, it's easiest to clone via the following URL:
ht
Andrew Dunstan wrote:
> I'm not sure if you've read all the archive history on this. Here are
> the pointers from the TODO list:
>
> http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php
> http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php
> http://archives.postgresql.org
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> One disadvantage is that one could no longer have objects that have names
> different only by case, but that is probably rare and incredibly stupid and
> can be neglected.
Certainly not if you hope to claim being within a mile of spec -- which seem
Peter Eisentraut wrote:
I have had some idle thoughts on the issue of identifier case folding. Maybe
we can collect our ideas and inch closer to a solution sometime. Or we
determine that it's useless and impossible, but then I can at least collect
that result in the wiki and point future us
In trying to port postgres to 64-bit Windows, I've encountered a
number of issues which may (or may not) affect other compilers. If
you followed the other thread, this is mostly a summary with a bit
more details so feel free to ignore it. Some of these may have some
minor effects on other platfor
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
> Do you think it's worthwhile to implement the LC algorithm in C and send
> it out, so others could try it out? Heck, maybe it's worthwhile to
> replace the current compute_minimal_stats() algorithm with LC and see
> how that compares
Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> Right. From a user's perspective 4) sounds best. I often run into problems
> having keywords as column-names:
None of the proposals on the table will remove the need to use quotes in
that case.
regards, tom lane
--
Sent
Jan Urbański wrote:
If you think the Lossy Counting method has potential, I could test it
somehow. Using my current work I could extract a stream of lexemes as
ANALYZE sees it and run it through a python implementation of the
algorithm to see if the result makes sense.
I hacked together a sim
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Josh Berkus <[EMAIL PROTECTED]> wrote:
>> Actually, there are a number of *very* popular database tools,
>> particularly
>> in the Java world (such as Netbeans and BIRT) which do mix quoted and
>> unquoted identifiers.
> Do these tools expect an unqu
>>> Ron Mayer <[EMAIL PROTECTED]> wrote:
> +1 for a compile-time option for spec-compliant behavior. Even
> where the spec is stupid (timestamp with time zone literals) it'd
> be nice to have the option; both for feature completeness
> checklists and for teachers who want to teach targeting th
Tom Lane wrote:
What I think would perhaps be worth investigating is a compile-time
(or at latest initdb-time) option that flips the case folding behavior
to SQL-spec-compliant and also changes all the built-in catalog entries
to upper case. We would then have a solution we could offer to people
>>> Josh Berkus <[EMAIL PROTECTED]> wrote:
> Actually, there are a number of *very* popular database tools,
particularly
> in the Java world (such as Netbeans and BIRT) which do mix quoted and
> unquoted identifiers. In general, users of those tools reject
PostgreSQL
> as "broken" for our non
On Tuesday 08 July 2008 23:04:51 Josh Berkus wrote:
> Tom,
>
> > IMHO, practically the only solid argument for changing from the way
> > we do things now is "to meet the letter of the spec". The various sorts
> > of gamesmanship you list would most definitely not meet the letter of
> > the spec;
Tom,
> IMHO, practically the only solid argument for changing from the way
> we do things now is "to meet the letter of the spec". The various sorts
> of gamesmanship you list would most definitely not meet the letter of
> the spec; between that and the inevitability of breaking some apps,
> I'm
Andrew Dunstan napsal(a):
Tom Lane wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec. I wonder why we are allowing a
nonstandard half-measure to drive our thinking, rath
Josh Berkus wrote:
Tom,
Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the "ident" IP
protocol.
The Solaris security & kernel folks do, actually. However,
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Martijn van Oosterhout napsal(a):
Not necessarily. pg_class is not shared yet without it you can't even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> I looked this over and it looks good in general.
> May I think that patch passed review and commit it?
I'd still like to take a look.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list
On 7/8/2008 11:38 AM, David Fetter wrote:
On Tue, Jul 08, 2008 at 06:22:23PM +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
SQL, in text form, is the interface to other databases. You can't
pass half a plan tree to Oracle, especially not a PostgreSQL plan
tree. It has to be text if you wis
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Dienstag, 8. Juli 2008 schrieb Tom Lane:
>> IMHO, practically the only solid argument for changing from the way
>> we do things now is "to meet the letter of the spec".
> Well no. As I have mentioned, there have actually been occasional complaints
Am Dienstag, 8. Juli 2008 schrieb Tom Lane:
> IMHO, practically the only solid argument for changing from the way
> we do things now is "to meet the letter of the spec".
Well no. As I have mentioned, there have actually been occasional complaints
by people who can't run their code generated by c
Josh Berkus <[EMAIL PROTECTED]> writes:
> Andrew, Tom,
>> Agreed. Are we even sure that we want per-database collations as a
>> half-way house? Unless we can be sure that we want all the required
>> catalog changes for the full requirement, it seems to me a rather messy
>> way of getting to where w
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I have had some idle thoughts on the issue of identifier case folding.
> ...
> Comments?
IMHO, practically the only solid argument for changing from the way
we do things now is "to meet the letter of the spec". The various sorts
of gamesmanship you l
On Tue, 2008-07-08 at 19:25 +0200, Peter Eisentraut wrote:
> 4. Compare the "name" data type in a case-insensitive manner. This
> would probably address most problem cases. Again, you can't have
> objects with names
> different in case only. One condition to implementing this would be
> that t
Josh Berkus wrote:
Tom,
Indeed. If the Solaris folk feel that getupeercred() is insecure,
they had better explain why their kernel is that broken. This is
entirely unrelated to the known shortcomings of the "ident" IP
protocol.
The Solaris security & kernel folks do, actually. Ho
I have had some idle thoughts on the issue of identifier case folding. Maybe
we can collect our ideas and inch closer to a solution sometime. Or we
determine that it's useless and impossible, but then I can at least collect
that result in the wiki and point future users to it.
Background: Pos
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
... And of course shared tables need also collation for their indexes.
No, they don't, because the only textual indexes on shared catalogs are
on "name" columns, which are intentionally not locale aware, and
wouldn't be collation aw
All,
> > The pgace_* scheme is an attractive idea, although the server process
> > has to provide a bit more hints (like the name of security system column
> > and the kind of objects exported with security attribute) pg_dump to
> > support various kind of security features with smallest implement
Tom,
> Indeed. If the Solaris folk feel that getupeercred() is insecure,
> they had better explain why their kernel is that broken. This is
> entirely unrelated to the known shortcomings of the "ident" IP
> protocol.
The Solaris security & kernel folks do, actually. However, there's no
questi
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Martijn van Oosterhout napsal(a):
Not necessarily. pg_class is not shared yet without it you can't
even
find pg_database. Same deal with pg_type. All it means is that
pg_collation in template1 must contain all the collations used in
t
Andrew, Tom,
> Agreed. Are we even sure that we want per-database collations as a
> half-way house? Unless we can be sure that we want all the required
> catalog changes for the full requirement, it seems to me a rather messy
> way of getting to where we want to go.
Given that we don't have a del
On 7/8/08, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
> > On 7/8/08, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > > First let me say that I too enjoy PL/Proxy quite a bit. However, I don't
> > > think it needs to be in core. I wouldn't
On 7/8/08, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-07-08 at 18:29 +0300, Marko Kreen wrote:
> > and potentially SPREAD BY as discussed in:
> >
> > http://lists.pgfoundry.org/pipermail/plproxy-users/2008-June/93.html
>
> That *sounds* cool, but its just the first part of the im
On 7/8/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Jaime Casanova escribió:
> > On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > The idea of this patch is to avoid the need to make explicit grants on
> > > sequences owned by tables.
> >
> > I've n
On Tue, 2008-07-08 at 08:58 -0700, Joshua D. Drake wrote:
>
> On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
> > On 7/8/08, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > > First let me say that I too enjoy PL/Proxy quite a bit. However, I don't
> > > think it needs to be in core. I would
On Tue, 2008-07-08 at 18:43 +0300, Marko Kreen wrote:
> On 7/8/08, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > First let me say that I too enjoy PL/Proxy quite a bit. However, I don't
> > think it needs to be in core. I wouldn't mind seeing it in contrib (or
> > better yet modules/ should we
On Tue, 2008-07-08 at 18:29 +0300, Marko Kreen wrote:
> and potentially SPREAD BY as discussed in:
>
>
> http://lists.pgfoundry.org/pipermail/plproxy-users/2008-June/93.html
>
That *sounds* cool, but its just the first part of the implementation of
a massively parallel executor. You'll qui
On 7/8/08, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-07-08 at 10:21 +0100, Simon Riggs wrote:
> > On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
>
> > I very much like PL/Proxy and support your vision. Including the
> > features of PL/Proxy in core seems like a great idea
On Tue, Jul 08, 2008 at 06:22:23PM +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> SQL, in text form, is the interface to other databases. You can't
>> pass half a plan tree to Oracle, especially not a PostgreSQL plan
>> tree. It has to be text if you wish to send a query to another
>> RDB
On 7/8/08, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
> > I mentioned that I planned to remove SELECT/CONNECT too.
> > Now I've thought about it more and it seems to me that its better
> > to keep them. As they give additional flexibility.
>
On Tue, 2008-07-08 at 10:21 +0100, Simon Riggs wrote:
> On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
>
> I very much like PL/Proxy and support your vision. Including the
> features of PL/Proxy in core seems like a great idea to me.
> Adding this feature for tables would be interesting
Simon Riggs wrote:
SQL, in text form, is the interface to other databases. You can't pass
half a plan tree to Oracle, especially not a PostgreSQL plan tree. It
has to be text if you wish to send a query to another RDBMS, or another
version of PostgreSQL.
Oh, I see. Agreed.
Though note that the
On Tue, 2008-07-08 at 17:51 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The notes say "Heikki doesn't think this is a long term solution", but
> > in the following discussion it was the *only* way of doing this that
> > will work with non-PostgreSQL databases. So it seems like the wa
On Tue, Jul 08, 2008 at 10:54:28AM -0400, Andrew Dunstan wrote:
> Agreed. Are we even sure that we want per-database collations as a
> half-way house? Unless we can be sure that we want all the required
> catalog changes for the full requirement, it seems to me a rather messy
> way of getting to
Tom Lane wrote:
All the argument here is based on the premise that we should have
database-level collation specifications, which AFAICS is not required
nor suggested by the SQL spec. I wonder why we are allowing a
nonstandard half-measure to drive our thinking, rather than solving the
real pr
Simon Riggs wrote:
The notes say "Heikki doesn't think this is a long term solution", but
in the following discussion it was the *only* way of doing this that
will work with non-PostgreSQL databases. So it seems like the way we
would want to go, yes?
How did you come to the conclusion that this
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> ... And of course shared tables need also collation for their indexes.
No, they don't, because the only textual indexes on shared catalogs are
on "name" columns, which are intentionally not locale aware, and
wouldn't be collation aware either.
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> It would be very useful if people would add a comment like "started my
> review of X now". Otherwise people don't know whether the reviewer is
> actually reviewing it at length, or just intend to at some point.
That's a good idea, imho, I'll try to do t
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout napsal(a):
>> Not necessarily. pg_class is not shared yet without it you can't even
>> find pg_database. Same deal with pg_type. All it means is that
>> pg_collation in template1 must contain all the collations used in
>> template1,
Jaime Casanova escribió:
> On Thu, May 22, 2008 at 1:18 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > The idea of this patch is to avoid the need to make explicit grants on
> > sequences owned by tables.
>
> I've noted that the patch i attached is an older version that doesn't
> co
Simon Riggs wrote:
On Mon, 2008-07-07 at 16:26 -0700, David Fetter wrote:
On Mon, Jul 07, 2008 at 06:46:29PM -0400, Andrew Dunstan wrote:
For the record, I agree with Jan's suggestion of passing a pointer
to the parse tree, and offline gave David a suggestion verbally as
to how this cou
On Mon, 2008-07-07 at 11:03 -0700, Josh Berkus wrote:
> Brendan,
>
> > What I'm saying is, I've got the opportunity and the inclination to
> > make the wiki more usable. If you guys want better navigation,
> > there's a suggestion on the table to improve that. I'm not too
> > worried about the
On Jul 7, 2008, at 7:39 PM, Tom Lane wrote:
Another point to keep in mind, if you are trying to analyze files
belonging to a live database, is that what you can see in the
filesystem
may not be the "current" contents of every page. For typical access
patterns it'd be unsurprising for the visi
On Mon, 2008-07-07 at 10:51 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-07-07 at 11:03 +0900, ITAGAKI Takahiro wrote:
> >> One issue is "tag" field. The type is now uint32. It's enough in my plugin,
> >> but if some people need to add more complex structures i
Martijn van Oosterhout napsal(a):
Oh I see, you're referring to the storage of the default collation for
a database. I was jumping ahead to the per-column collation state, when
the collation default is attached to columns, types and domains, and
not at the database level. So there the problem do
On Tue, Jul 08, 2008 at 12:00:34PM +0200, Zdenek Kotala wrote:
> >Not necessarily. pg_class is not shared yet without it you can't even
> >find pg_database. Same deal with pg_type. All it means is that
> >pg_collation in template1 must contain all the collations used in
> >template1, which shouldn'
Martijn van Oosterhout napsal(a):
On Tue, Jul 08, 2008 at 11:27:35AM +0200, Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
I though more about it and I discussed it with Radek yesterday. The
problem is that collation must be created before user want to use CREATE
DATABASE ... COLLATE ... comma
On Tue, Jul 08, 2008 at 11:27:35AM +0200, Zdenek Kotala wrote:
> Zdenek Kotala napsal(a):
>
> >
> >I though more about it and I discussed it with Radek yesterday. The
> >problem is that collation must be created before user want to use CREATE
> >DATABASE ... COLLATE ... command. It inclines to h
Zdenek Kotala napsal(a):
I though more about it and I discussed it with Radek yesterday. The
problem is that collation must be created before user want to use CREATE
DATABASE ... COLLATE ... command. It inclines to have have pg_collation
as a global catalog, but ANSI specifies to use schema
On Sat, 2008-06-28 at 16:36 +0300, Marko Kreen wrote:
> I mentioned that I planned to remove SELECT/CONNECT too.
> Now I've thought about it more and it seems to me that its better
> to keep them. As they give additional flexibility.
I very much like PL/Proxy and support your vision. Including
KaiGai Kohei wrote:
Might want to change the option name --enable-selinux to something
like --security-context.
In general, we might want to not name things selinux_* but instead
sepostgresql_* or security_* or security_context_*. Or maybe PGACE?
The pgace_* scheme is an attractive idea, alt
Here is the patches he made against CVS HEAD (as of today).
According to him followings are fixed with the patches:
- fix crush with DISTINCT
- fix creating VIEW
- fix the case when recursion plan has another recursion plan under it
- fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong res
Tom Lane napsal(a):
Gregory Stark <[EMAIL PROTECTED]> writes:
Out of curiosity, what is a "user-defined collation"? Are there SQL statements
to go around declaring what order code points should be sorted in? That seems
like it would be... quite tedious!
We might be best off to treat colla
On Mon, Jul 7, 2008 at 6:36 PM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Dave Page wrote:
>>
>> it concerns me that despite it being day 3 of the July commit fest,
>> people are still being advised to add new items to the wiki page.
>>
>> To make the idea work, we need to stick to the rules we defi
Martijn van Oosterhout napsal(a):
On Mon, Jul 07, 2008 at 12:06:08PM -0700, David E. Wheeler wrote:
I guess that'd be the reason to keep it on pgFoundry, but I have two
comments:
* 2-3 years is a *long* time in Internet time.
There have been patches over the years, but they tend not to get
68 matches
Mail list logo
