From: Tom Lane mailto:t...@sss.pgh.pa.us>>
Date: August 19, 2010 10:25:36 AM PDT
To: David Fetter mailto:da...@fetter.org>>
Cc: Kevin Grittner
mailto:kevin.gritt...@wicourts.gov>>, Robert Haas
mailto:robertmh...@gmail.com>>, Pavel Stehule
mailto:pavel.steh...@gmail.com>>, Greg Stark
mailto:gsst
On Thu, Jun 3, 2010 at 1:23 PM, Marc Munro wrote:
> On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
> wrote:
>> [ . . . ]
>>
>> In my current idea, when a qual-node that contains FuncExpr tries to
>> reference a part of relations within a security view, its referencing
>> rel
On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
> [ . . . ]
>
> In my current idea, when a qual-node that contains FuncExpr tries to
> reference a part of relations within a security view, its referencing
> relations will be expanded to whole of the security view at
> d
>
> -- Forwarded message --
> From: Greg Stark
> To: Simon Riggs
> Date: Sun, 30 Aug 2009 00:28:14 +0100
> Subject: Re: LWLock Queue Jumping
> On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs wrote:
> > WALInsertLock is heavily contended and likely always will be even if we
> > apply
On Thu, Aug 27, 2009 at 01:12:20PM -0400, Robert Haas wrote:
> This is pretty cool, IMO. Admittedly, it does seem hard to bottle it,
> but you managed it, so it's not completely impossible. What you could
> for this kind of thing is a series of patches and driver scripts, so
> you build PostgreSQ
On Thu, Aug 27, 2009 at 12:47 PM, Jeff Janes wrote:
>> -- Forwarded message --
>> From: Tom Lane
>> To: Robert Haas
>> Date: Thu, 27 Aug 2009 10:11:24 -0400
>> Subject: Re: 8.5 release timetable, again
>>
>> What I'd like to see is some sort of test mechanism for WAL recovery.
>>
>
> -- Forwarded message --
> From: Tom Lane
> To: Robert Haas
> Date: Thu, 27 Aug 2009 10:11:24 -0400
> Subject: Re: 8.5 release timetable, again
>
> What I'd like to see is some sort of test mechanism for WAL recovery.
> What I've done sometimes in the past (and recently had to
Jeff Janes wrote:
> But the fact that a piece of code was executed doesn't mean
> it did the right thing. If it does something subtly wrong,
> will we notice?
That's why it takes some time to fashion a decent test.
On the other hand, if code is not being exercised at at all during the
beta
>
> -- Forwarded message --
> From: "Kevin Grittner"
> To: "Robert Haas" , "Bruce Momjian" <
> br...@momjian.us>
> Date: Thu, 27 Aug 2009 09:07:05 -0500
> Subject: Re: 8.5 release timetable, again
> Robert Haas wrote:
>
> > Maybe we should be looking at an expanded test suite that
a fur cap on his head. The sledge drove round the square twice, and Kay tied on
and thus spake [EMAIL PROTECTED] [2008.05.07 @ 16:23]:
> Date: Wed, 07 May 2008 11:18:48 -0400
> From: Andrew Dunstan <[EMAIL PROTECTED]>
> > If you want an email and web-based tracking system, RT is wonderful
> > (http://bestpractical.com/rt/)...
>
> STOP!
Sorry for biting... I just couldn't re
On Mon, 2006-10-02 at 12:02 -0300, Shaunak Godbole wrote:
> Hi,
>
> We are trying to introduce access control. For this we have to rewrite
> the
> input query by replacing each relation by its corresponding authorized
> view.
I assume from this that you are trying to implement something like
Orac
On Fri, 2006-05-19 at 13:41 -0300, [EMAIL PROTECTED]
wrote:
> Marc Munro wrote:
> > Veil http://pgfoundry.org/projects/veil is currently not a very good
> > Postgres citizen. It steals what little shared memory it needs from
> > postgres' shared memory using ShmemAlloc().
> >
> > For Postgres 8.
On 5/5/06, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
On 5/5/06, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
> If it is such a 'simple porting', may I ask why hasn't it been
> attempted successfuly in so many years of PG's history?
Because most of use don't use Windows... I thought I said that.
B
`vcproject` is based on pgsql-8.0.3. It's purpose is to make pgsql built
with MSVC++.
But I found there are few people intrested on it, so I stopped maintaining
it months
ago. `vcproject` still need MSYS/MinGW, the basic idea behind it is:
1) Let we do configure, make, make install in MinGW first.
Gurjeet Singh wrote:
My main grudge is that if we are supporting almost all flovours of
nixens and compilers (close to 34 according to official website), then
why are we leaving Windows platform alone? This will bring in quite a
lot more developers.
You should look at MinGW as a development t
On Mon, 21 Nov 2005, Marc Munro wrote:
I wonder if this idea might be taken a little further, to allow
read-only tablespaces?
This would allow old partitions in very large databases to be kept on
read-only media, and would allow normal backups to ignore this
unchanging set of data.
I guess yo
I wonder if this idea might be taken a little further, to allow
read-only tablespaces?
This would allow old partitions in very large databases to be kept on
read-only media, and would allow normal backups to ignore this
unchanging set of data.
It also allows for certain specific optimisations for
Magnus Hagander wrote:
> > It occurs to me that there is no longer any great need to
> > have a separate hackers list for win32 development. Perhaps
> > we should close it down now and keep all development on -hackers?
>
> I also think this is a good idea. The number of "win32 only issues of
> -
Magnus Hagander schrieb:
It occurs to me that there is no longer any great need to
have a separate hackers list for win32 development. Perhaps
we should close it down now and keep all development on -hackers?
I also think this is a good idea. The number of "win32 only issues of
-hacker level"
> It occurs to me that there is no longer any great need to
> have a separate hackers list for win32 development. Perhaps
> we should close it down now and keep all development on -hackers?
I also think this is a good idea. The number of "win32 only issues of
-hacker level" is significantly smal
Rob Butler wrote:
... SVN also has a number of nice features
like atomic commits, versioning directories, etc.
Still, subversion identifies file content by it's location in the
directory tree which makes the directory versioning a lot less useful
than it could have been. Renaming directories or e
Rob Butler wrote:
[details of some SVN features]
please see reecent debates on the topic of SCM systems.
"Those who do not remember the debates on the mailing lists are bound to
repeat them."
cheers
andrew
---(end of broadcast)---
TIP 2: you can
>
> >2) As long as we're using CVS, the only way to
> organize autonomous project
> >teams that have authority over their special areas
> but no ability to change
> >central code is to "push out" projects to separate
> CVS trees.
> >
> >
> This has never been an issue before, AFAIK, nobody
> w
That is pretty much where we are ;-)
I think we're fine for 8.0.x with this, because if you actually need
UTF-8 (and can live with sorting broken, no upper/lower etc), you can do
it using a manual initdb.
For 8.1, I think the ICU approach looks a lot more promising than trying
to do "on the fly co
1 AM
> To: John Hansen
> Cc: Bruce Momjian; Tatsuo Ishii; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
>
> "John Hansen" <[EMAIL PROTECTED]> writes:
> > Look at t
"John Hansen" <[EMAIL PROTECTED]> writes:
> Look at the upper/lower I sent to the list, they should be able to
> replace upper/lower for the utf8 encoding (and works independent of
> locale)..
I was under the impression we couldn't use these, precisely because they
weren't locale-aware. ("It
PM
> To: John Hansen
> Cc: Tatsuo Ishii; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
>
> John Hansen wrote:
> > Look at the upper/lower I sent to the list, the
ay, April 24, 2005 10:35 PM
> To: Tatsuo Ishii
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
>
>
> Where are we on this? As far as I can tell, we never dis
MAIL PROTECTED];
> > [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32
> >
> >
> > Where are we on this? As far as I can tell, we never disabled UTF8 on
> > Win32 in our code. The only thing we
Where are we on this? As far as I can tell, we never disabled UTF8 on
Win32 in our code. The only thing we did do was to disable UTF8 in
pginstaller. See this FAQ item:
http://pginstaller.projects.postgresql.org/faq/FAQ_windows.html#2.6
Is the current setup OK? Should we allow UTF8 o
Tatsuo Ishii wrote:
> I do understand the problem, but don't undertstand the decision you
> guys made. The fact that UPPER/LOWER and some other functions does not
> work in win32 is surely a problem for some languages, but not a
> problem for otheres. For example, Japanese (and probably Chinese and
Peter Eisentraut wrote:
> > o Disallow encodings like UTF8 which PostgreSQL supports
> > but the operating system does not (already disallowed by
> > pginstaller)
>
> I think the warning that initdb shouts out is already enough for this.
> I don't think we want to dis
I have reviewed this patch, and I already added these changes myself in
CVS.
Thanks.
---
Nicolai Tufar wrote:
> > On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote:
> >
> > Applied.
>
> Thanks a lot. The patch
Would you please check current CVS? I think I addressed most of these
issues already.
---
Nicolai Tufar wrote:
> > On Mon, Feb 21, 2005 at 10:53:08PM -0500, Bruce Momjian wrote:
> >
> > Applied.
>
> Thanks a lot. The patch
Nicolai Tufar wrote:
> On Tue, 01 Mar 2005 17:45:31 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Nicolai Tufar <[EMAIL PROTECTED]> writes:
> > Just out of curiosity, do either HAVE_INT64 or HAVE_UINT64 get set
> > in pg_config.h? The observed symptoms would be explained if typedef
> > int64 were
On Tue, 01 Mar 2005 17:45:31 -0500, Tom Lane > Just out of curiosity,
do either HAVE_INT64 or HAVE_UINT64 get set
> in pg_config.h?
pg_config.h is attached. What drew my attention is the
following declaration:
/* Define to 1 if `long long int' works and is 64 bits. */
#define HAVE_LONG_LONG_INT
Nicolai Tufar <[EMAIL PROTECTED]> writes:
> Amazingly enough HAVE_LONG_LONG_INT_64 is
> defined when compilation comes to src/port/snprintf.c
> but the result is still wrong. I looked into configure.in
> but the check for HAVE_LONG_LONG_INT_64 is too
> complicated for me to understand. Bruce, could
"John Hansen" <[EMAIL PROTECTED]> writes:
> Right, so for the sample SQL I sent earlier, the result would be the same as
> the input?
> That's hardly a working upper/lower
[ shrug... ] It works per the locale definition, which is that only
7-bit-ASCII a-z/A-Z get converted.
The bottom line
> On HPUX 10.20, mbstowcs seems to treat all byte values as
> single-byte characters in C locale, so my sample-of-one says
> that it works everywhere ;-).
Right, so for the sample SQL I sent earlier, the result would be the same as
the input?
That's hardly a working upper/lower
If a charac
"John Hansen" <[EMAIL PROTECTED]> writes:
>> "It fails on my machine" should not be read as "it doesn't
>> work for anyone".
>> It all depends on how your local mbstowcs() works.
> Ok,... Do you have an example of a system on which it works?
On HPUX 10.20, mbstowcs seems to treat all byte values
On Fri, 25 Feb 2005, Peter Eisentraut wrote:
Josh Berkus wrote:
I thought we were trying to get away from a midsummer feature freeze,
due to the general lack of personnel in that season?
Better to do feature freeze with no one around than development or
release preparations with no one around, no?
> > select upper('æøå');
> > ERROR: invalid multibyte character for locale
> > HINT: The server's LC_CTYPE locale is probably
> incompatible with the database encoding.
>
> > Consequently it seems that is does not work.
>
> "It fails on my machine" should not be read as "it doesn't
> work for
Josh Berkus wrote:
> I thought we were trying to get away from a midsummer feature freeze,
> due to the general lack of personnel in that season?
Better to do feature freeze with no one around than development or
release preparations with no one around, no?
--
Peter Eisentraut
http://developer.
Tom,
> As a proposal: feature freeze maybe early summer (June or July), beta
> maybe Aug/Sep, final as always "when it's ready" (maybe Oct/Nov with
> a good tailwind).
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season? I c
"John Hansen" <[EMAIL PROTECTED]> writes:
>> Sure it does. It's just that the defined behavior of the C
>> locale is often useless in practice.
> select upper('æøå');
> ERROR: invalid multibyte character for locale
> HINT: The server's LC_CTYPE locale is probably incompatible with the
> datab
On Thu, 24 Feb 2005 22:18:11 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Didn't we do that already?
No :( I promised to do it a couple of weeks ago but could not get to do it.
Now with Magnus's help I finaly did it. The last patch should be fine.
> regards, tom lane
Nic
> John Hansen wrote:
> > currently, upper/lower does not work with 2+ byte unicode
> characters,
> > on any OS under the C locale.
>
> Sure it does. It's just that the defined behavior of the C
> locale is often useless in practice.
select upper('æøå');
ERROR: invalid multibyte character for
John Hansen wrote:
> currently, upper/lower does not work with 2+ byte unicode characters,
> on any OS under the C locale.
Sure it does. It's just that the defined behavior of the C locale is
often useless in practice.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
-
Bruce Momjian wrote:
> Oh, sorry. So there is no ordering in Unicode?
That statement is meaningless. Unicode is a character set, not a
collation order.
> No wonder some
> languages can't use Unicode effectively.
That has nothing to do with it.
> o Disallow encodings like UTF8 which
Tom Lane wrote:
> Bruce Momjian writes:
> > Your patch has been added to the PostgreSQL unapplied patches list at:
>
> Didn't we do that already?
This patch is for thread safety:
> Thanks a lot. The patch attached solves the tread
> safety problem. Please review it before applying,
> I am not s
Bruce Momjian writes:
> Your patch has been added to the PostgreSQL unapplied patches list at:
Didn't we do that already?
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ni
> currently, upper/lower does not work with 2+ byte unicode
> characters, on any OS under the C locale.
Btw,...
There are only 15 cases in the utf8 repertoire that depends on locale, these
are the only cases where pg should report:
ERROR: invalid multibyte character for locale
HINT: The serv
"John Hansen" <[EMAIL PROTECTED]> writes:
> Right,. So if that's fixed, then UTF8 will work only on windows?
No.
> (currently, upper/lower does not work with 2+ byte unicode characters, on any
> OS)
This information is obsolete.
regards, tom lane
--
K, let me rephrase:
currently, upper/lower does not work with 2+ byte unicode characters, on any OS
under the C locale.
... John
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining colu
> To fix UTF8, the data needs to be converted to
> UTF16 and then
> the Win32 wcscoll() can be used, and perhaps other functions
> like towupper(). However, UTF8 already works with normal
> locales but provides no ordering.
Right,. So if that's fixed, then
Magnus Hagander wrote:
> The installer does not permit it, but initdb lets you do anything yuo
> want - I think that's where we are. If you know what you're doing, you
> can use it by manually initdbing.
>
> There is no such thing as "unicode locale". Unicode (UTF8) is an
> encoding, that has to b
The installer does not permit it, but initdb lets you do anything yuo
want - I think that's where we are. If you know what you're doing, you
can use it by manually initdbing.
There is no such thing as "unicode locale". Unicode (UTF8) is an
encoding, that has to be paired with a locale. I assume yo
Magnus, where are we on this? Seems we should allow unicode encoding
and just not unicode locale in pginstaller.
Also, Unicode is changing to UTF-8 in 8.1.
---
Tatsuo Ishii wrote:
> I do understand the problem, but don't
On Sun, 13 Feb 2005 19:06:34 -0500 (EST), Bruce Momjian
wrote:
> Anyway, this is too large to put into 8.0, but I am attaching a patch
> for 8.1 that has the proper configure tests to check if the C library
> supports this behavior. If it does not, the build will use our
> port/snprintf.c.
> One
I have added this syntax to the TODO list:
* Allow GRANT/REVOKE permissions to be applied to all schema objects with one
command
The proposed syntax is:
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
---
Nicolai Tufar wrote:
> Hello all,
>
> I would like to submit my changes to src/port/snprintf.c to
> enable %n$ format placeholder replacement in snprintf() and
> vsnprintf(). Additionally I implemented a trivial printf().
>
> I also attach a diff for configure.in to include snprintf.o
> in pgport
Marc,
> alot smoother today then it went yesterday ... and faster ... but, then
> again, *most* clients use <256MB of storage, so moving their VM around
> takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox
> alone ... and i miscalculated how long it would take to move it ba
On Mon, 31 Jan 2005, Josh Berkus wrote:
Marc,
And to be perfectly frank, I was mostly thinking of Marc when I said that.
Sorry, that was uncharitable. I meant that (at the time) you were panicking.
Wait, I've not panic'd about all of this at any point ... the only
'chicken little' comment I made
On Mon, 31 Jan 2005, Josh Berkus wrote:
Now you have something different to panic about. How goes the server
shuffle?
alot smoother today then it went yesterday ... and faster ... but, then
again, *most* clients use <256MB of storage, so moving their VM around
takes no time ... svr1 is @ ~13G :
Hi *,
I will start implementing this stuff based on this syntax:
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
so there are two seperate commands to use.
is everybody fine with this aproach?
cheers,
Matthias
PS.: Tom, shouldn't we mention the fact
Josh Berkus wrote:
Guys,
BTW, if you hadn't guessed, that comment was supposed to be off-list.
Unfortunately, I discovered a bug with KMail and list management, the hard
way ...
Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if
you have list management turned on, it s
Marc,
> And to be perfectly frank, I was mostly thinking of Marc when I said that.
Sorry, that was uncharitable. I meant that (at the time) you were panicking.
Now you have something different to panic about. How goes the server
shuffle?
--
Josh Berkus
Aglio Database Solutions
San Franci
Andrew,
> On Thu, Jan 27, 2005 at 10:39:52AM -0800, Josh Berkus wrote:
> > Thanks. As you know, I'm getting a little sick of the chicken little
> > act among many of the -hackers
>
> I think this is a little bit of a mischaracterisation. Afilias is
> already a customer of IBM.
BTW, if y
Guys,
> BTW, if you hadn't guessed, that comment was supposed to be off-list.
> Unfortunately, I discovered a bug with KMail and list management, the hard
> way ...
Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if
you have list management turned on, it sometimes send
On Saturday 29 January 2005 09:14, Stephen Frost wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > Or just make the user enter two commands for this case. Aside from
> > syntactic simplicity, that might be a good idea anyway. The NEW TABLES
> > case is *fundamentally* different from every other
On Saturday 29 January 2005 11:33, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I'm not mischarecterizing, I just feel that putting out an lru based
> > 8.0.x release is such a bad idea that I'd rather do (1) than gamble on
> > (2).
>
> I don't understand why you think it's such a
Robert Treat <[EMAIL PROTECTED]> writes:
> I'm not mischarecterizing, I just feel that putting out an lru based 8.0.x
> release is such a bad idea that I'd rather do (1) than gamble on (2).
I don't understand why you think it's such a bad idea. We do have the
problem of getting adequate testin
On Friday 28 January 2005 12:36, Josh Berkus wrote:
> Robert,
>
> > Read the law... willful vs. unknown infringement are two different
> > things.
>
> We're not infringing anything, yet. That's a *pending* patent.
>
*sigh* Thats understood. But you were using the counter-argument that we
migh
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Or just make the user enter two commands for this case. Aside from
> syntactic simplicity, that might be a good idea anyway. The NEW TABLES
> case is *fundamentally* different from every other form of GRANT, in
> that it causes future actions. So it might
Josh Berkus writes:
> GRANT SELECT ON ALL, NEW TABLES IN public TO phpuser;
> ... does both.
Ah, I overlooked that part of your message. I think the above probably
doesn't work in bison, but if not we could spell it like
GRANT SELECT ON ALL AND NEW TABLES IN public TO phpuser;
Or just make t
Josh Berkus writes:
> Hmm, what about using, ALL and NEW? i.e.
> GRANT SELECT ON NEW TABLES IN public TO phpuser;
> GRANT SELECT ON ALL TABLES IN public TO phpuser;
That seems good to me. More generally it would be
GRANT perm [,...] ON NEW/ALL TABLES IN schema [,...] TO user [,...]
Tom,
> This however seems a rather whimsical reinvention of the meaning of
> CASCADE. ÂI'm not sure if we really need to support both immediate and
> delayed inheritance of privileges from a schema, but if we do, let's
> please use some other keyword than CASCADE to distinguish the cases.
> Also i
Josh Berkus writes:
> Can't say I like either. I'd prefer:
> GRANT [PERM] ON ALL TABLES IN SCHEMA [schemaname] TO [user];
I agree that this syntax seems more SQL-ish than relying on a wildcard.
> GRANT SELECT, UPDATE, INSERT ON TABLES IN SCHEMA public TO php-user;
> .. would set the defaul
Josh Berkus writes:
> Why 10? I'd think we could come up with a slightly less arbitrary number,
Well, it's probably within an order of magnitude of the right thing ;-).
We know we don't want 1, but 100 seems awfully optimistic.
If someone can come up with a more defensible number then I'm all
Matt,
> a) accept some sort of wildcard for the grant on table syntax:
> Â Â GRANT ... ON TABLE schema.*
>
> b) use something like CASCADE for the grant on schema syntax:
> Â Â GRANT ... ON SCHEMA CASCADE
> Â Â In this case the grant on schema's need to swallow the permissions
> Â Â (SELECT, INSER
Tom,
> The only real solution, of course, is to acquire cross-column
> statistics, but I don't see that happening in the near future.
Y'know, that's been on the todo list for a while. Surely someone is inspired
for 8.1/8.2? At least for columns which are indexed together?
> As a short-term
Robert,
> Read the law... willful vs. unknown infringement are two different
> things.
We're not infringing anything, yet. That's a *pending* patent.
> Um... thats the way our legal system works. You could do that to any
> project if you had a patent they were infringing upon no matter how
> s
On Thu, 2005-01-27 at 12:51, Josh Berkus wrote:
> We don't *have* to do anything when the patent is granted. When we *have*
> to
> do something is when IBM sends a cease-and-desist letter to a PostgreSQL
> user. Not before.
>
With that attitude we don't have to do anything even then. We hav
Josh,
> >>Bruce is advocating waiting until the Patent has been Granted, instead of
> >>doing something about it now, when we know the patent is going through
> >> the system (and will likely get granted) ... a "reactive" vs "proactive"
> >> response to the problem.
>
> Very well written Josh.
Th
Marc, Tom, Robert, Bruce, et al:
> Bruce is advocating waiting until the Patent has been Granted, instead of
> doing something about it now, when we know the patent is going through the
> system (and will likely get granted) ... a "reactive" vs "proactive"
> response to the problem.
No, we're rea
On Sun, Jan 23, 2005 at 02:53:11PM -0800, Josh Berkus wrote:
> Jim,
>
> > Perhaps a good way to accomplish both goals is to have the set of
> > human-readable views, and to add columns to the system tables/views that
> > conform with the new, more logical naming convention. This way people
> > acc
Jim,
> Perhaps a good way to accomplish both goals is to have the set of
> human-readable views, and to add columns to the system tables/views that
> conform with the new, more logical naming convention. This way people
> accessing system information programmatically can use pg_catalog (and
> migr
On Sun, Jan 23, 2005 at 02:37:28PM -0800, Josh Berkus wrote:
> Jim,
>
> > It's a question of if these views will also be used programatically.
> > ISTM that OIDs are the preffered method of refering to things in code
> > (in fact, aren't there some functions that only take OIDs?). If we want
> > t
Jim,
> It's a question of if these views will also be used programatically.
> ISTM that OIDs are the preffered method of refering to things in code
> (in fact, aren't there some functions that only take OIDs?). If we want
> to make names the cannonical way to reference things in code, then I
> agr
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Is the long term plan to remove OIDs entirely?
No. OIDs will be the real primary keys of most system catalogs for the
foreseeable future. The only discussion that's going on concerns
deprecating their use in user tables.
regar
On Sun, Jan 23, 2005 at 12:43:15PM -0800, Josh Berkus wrote:
> BTW, People, I really don't see the point in prodiving a dual list -- that
> is,
> a list of OIDs in addition to the list of names provided in the columns of
> each view. The idea of these views is to keep the users *away* from
>
Troels, Others,
> Generally: Nice. But have you considered if the INFORMATION_SCHEMA could
> be used? Unfortunately, the INFORMATION_SCHEMA currently has a major
> problem in its usefulness in PostgreSQL:
> http://troels.arvin.dk/db/rdbms/#cli-list_of_tables-postgresql-gotchas
Actually, I did. H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Fri, 21 Jan 2005, Josh Berkus wrote:
OK, is anyone opposed to this idea? I would register a pgfoundry
project (name suggestions? "translations"?), give most established
translators commit access, and move the statistics pages there.
BTW, there i
Peter, Euler, others:
> > OK, is anyone opposed to this idea? ÂI would register a pgfoundry
> > project (name suggestions? "translations"?), give most established
> > translators commit access, and move the statistics pages there.
BTW, there is already a "translators" mailing list. While I've b
> On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote:
>> I have already
>> suggested to core that we should insist on 8.1 not requiring an initdb,
>> so as to ensure that people will migrate up to it easily from 8.0.
> So is it firm policy that changes that require a catversion update
> cannot be m
On Mon, 17 Jan 2005 14:54:44 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Also, it looks like src/port/snprintf.c is not %n$ capable either.
> I'm not sure which platforms that affects.
>
> A possible route to a solution is to upgrade snprintf.c and then use
> it on platforms that don't have this
>> I don't think we'll hold up release to fix this, but the affected
>> translators may want to think about whether they can avoid
>the problem
>> or not.
>
>Also, it looks like src/port/snprintf.c is not %n$ capable either.
>I'm not sure which platforms that affects.
>
>A possible route to a solu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 17 Jan 2005, Tom Lane wrote:
I don't think we'll hold up release to fix this,
:-) It seems nothing seems to stop you from holding up this release
anymore: Neither ARC problem nor this one :)
Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org,
1 - 100 of 212 matches
Mail list logo
