Fabien COELHO wrote:
>
> Dear Thomas,
>
> > My point is, in order to maintain a good separation of concern, I
> > should not use this knowledge.
>
> I agree.
>
> > IMHO, there's a need for a well documented "module extension build API"
> > accessible from a well known place.
>
> Sure.
>
> I'm
I was wanting to check out what was up with timezone handling with the
latest changes that were committed, as there had been some "biting" on
AIX.
To wit, notice the default time zone on one of our AIX boxes:
bash-2.05a$ date
Tue May 18 21:47:37 GDT 2004
bash-2.05a$ echo $TZ
CUT0GDT
bash-2.05a$
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>>> That would be great if a C function could find out what schema it had
>>> been declared in, but I don't think it can readily do so.
>>
>> TODO candidate ?
> Seems like it would be a good thing.
I take that back: you can find it out if you r
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > If we determine the default data directory off the configure option
> > --localstatedir then we can simply use the same mechanisms that have
> > been discussed for determining all the other directories at run time
> > relative to
On Wed, 19 May 2004, Andrew Dunstan wrote:
> > Why not have seperate branches in CVS for each version? Branch on
> > similar dates to the core distribution itself?
> >
>
> And thus demolish your argument that it is in the interests of projects to
> have independent release dates. And make the tas
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I don't think we have ever changed oids for existing data types, so you
>> should be OK.
> Are you sure? If we remove a type, then its oid becomes up for grabs by
> the unused_oids script.
But if we remove a type then it's a bit moot whethe
Christopher Kings-Lynne wrote:
> > Not sure. Most of the system stuff is loaded in a pretty good order, and
> > cluster is only good if you are going after seveal rows of identical
> > value or similar value in the same table, and I can't think of a case
> > where this would help. Can others? It
Alvaro Herrera wrote:
> On Wed, May 19, 2004 at 09:43:22PM -0400, Bruce Momjian wrote:
> > Christopher Kings-Lynne wrote:
> > > Is it worth us marking any system catalog indexes as clusterable by
> > > default for performance?
> >
> > Not sure. Most of the system stuff is loaded in a pretty good
Hello pgsql-hackers,
Following a recent discussion on the JDBC list
(http://archives.postgresql.org/pgsql-jdbc/2004-05/msg00100.php) I'm
looking at modifying when unnamed statements received via a v3 protocol
Parse message are planned. The idea is to delay planning until the Bind
message arrive
>>>You may not distribute this tool without the express written
>>>permission of Mark Russinovich.
>>
>>
>> Then by no means should *any* of that code be included into PostgreSQL.
>> In
>> fact, comments should not even make reference to it.
>
> May I point out that there is a heap of debate about
Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> Hmm. The inet = operator is marked hashable in 7.4 but not in 7.3 ...
>>> I wonder if that is a mistake?
>>
>> Digging further, I find that indeed this seems to be a mistake.
> This has not been fixed yet, right?
Right, it's still on the to-do list.
Added to TODO:
o Add ALTER DOMAIN TYPE
---
Rod Taylor wrote:
> > > Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
> > > (basically following the same rules as ALTER TABLE).
> >
> > Intere
Not sure. Most of the system stuff is loaded in a pretty good order, and
cluster is only good if you are going after seveal rows of identical
value or similar value in the same table, and I can't think of a case
where this would help. Can others? It is a good question.
pg_attribute would commonly
On Wed, May 19, 2004 at 09:43:22PM -0400, Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> > Is it worth us marking any system catalog indexes as clusterable by
> > default for performance?
>
> Not sure. Most of the system stuff is loaded in a pretty good order, and
> cluster is only good
On Thu, 20 May 2004, Christopher Kings-Lynne wrote:
> >>You may not distribute this tool without the express written
> >>permission of Mark Russinovich.
> >
> >
> > Then by no means should *any* of that code be included into PostgreSQL. In
> > fact, comments should not even make reference to it.
>
Christopher Kings-Lynne wrote:
> > True, but have we ever removed types? I can't think of one.
>
> Hmmm...perhaps.
>
> >>We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
> >>be surprised if we haven't _already_ reused those oids...
> >
> > Yes, for functions that is very
Christopher Kings-Lynne wrote:
> Is it worth us marking any system catalog indexes as clusterable by
> default for performance?
Not sure. Most of the system stuff is loaded in a pretty good order, and
cluster is only good if you are going after seveal rows of identical
value or similar value in t
Christopher Kings-Lynne wrote:
> > I don't think we have ever changed oids for existing data types, so you
> > should be OK.
>
> Are you sure? If we remove a type, then its oid becomes up for grabs by
> the unused_oids script.
True, but have we ever removed types? I can't think of one.
> We h
[EMAIL PROTECTED] wrote:
Peter Galbavy wrote:
You may not distribute this tool without the express written
permission of Mark Russinovich.
Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.
Does anybody have that "written
True, but have we ever removed types? I can't think of one.
Hmmm...perhaps.
We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
be surprised if we haven't _already_ reused those oids...
Yes, for functions that is very true.
I wonder if that has any implications for future binar
I don't think we have ever changed oids for existing data types, so you
should be OK.
Are you sure? If we remove a type, then its oid becomes up for grabs by
the unused_oids script.
We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
be surprised if we haven't _already_ reuse
You may not distribute this tool without the express written
permission of Mark Russinovich.
Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.
May I point out that there is a heap of debate about whether or not we
can u
Marc G. Fournier said:
> On Wed, 19 May 2004, Andrew Dunstan wrote:
>
>> Personally, I hate the idea of having to write stuff like this example
>> Joe Conway gave the other day from PL/R:
>>
>> #if (CATALOG_VERSION_NO <= 200211021)
>> #define PG_VERSION_73_COMPAT
>> #elif (CATALOG_VERSION_NO <= 200
This has not been fixed yet, right?
---
Tom Lane wrote:
> I wrote:
> > Michael Fuhr <[EMAIL PROTECTED]> writes:
> >> I have a query that works in 7.3.6 but not in 7.4.2 unless I turn
> >> off enable_hashjoin. I'm joining a
Marc G. Fournier said:
> On Wed, 19 May 2004, Josh Berkus wrote:
>
>> People,
>>
>> > >So, why tie it into the PostgreSQL source tree? Won't it be
>> > >popular enough to live on its own, that it has to be distributed as
>> > >part of the core?
>>
>> Personally, I find it rather inconsistent to ha
Dave Cramer wrote:
> How much can we count on the type oid's remaining static from version to
> version? It turns out there is a design decision in the jdbc driver that
> could fail if they changed from one version to another and the client
> connected to both versions.
I don't think we have ever
On Wed, 19 May 2004, Bruce Momjian wrote:
> The Win32 project page already has nightly Win32 builds courtesy of
> Magnus.
Do you want to setup an scp into the main ftp site so that the mirrors
catch them as well? Might make it easier for ppl to get ahold of it ...
Marc G. Fournier
On Wed, 19 May 2004, [ISO-8859-1] Hans-Jürgen Schönig wrote:
> If people think this is a good idea I could compile and maintain this
> (source) distribution ...
I'd love to see something like this ...
One question I have is what would it take to extend teh build system in
core so that it was eas
On Wed, 19 May 2004, Josh Berkus wrote:
> Tom,
>
> > The main downside of testing a snapshot, as I see it, is that the
> > snapshot is virtually certain not to be initdb-compatible with either
> > the previous release or the upcoming one. Mini-releases would have
> > that problem too, and so I do
On Wed, 19 May 2004, Andrew Dunstan wrote:
> Personally, I hate the idea of having to write stuff like this example
> Joe Conway gave the other day from PL/R:
>
> #if (CATALOG_VERSION_NO <= 200211021)
> #define PG_VERSION_73_COMPAT
> #elif (CATALOG_VERSION_NO <= 200310211)
> #define PG_VERSION_74_
On Wed, 19 May 2004, Josh Berkus wrote:
> People,
>
> > >So, why tie it into the PostgreSQL source tree? Won't it be popular
> > >enough to live on its own, that it has to be distributed as part of the
> > >core?
>
> Personally, I find it rather inconsistent to have any PL, other than
> PL/pgSQL,
How much can we count on the type oid's remaining static from version to
version? It turns out there is a design decision in the jdbc driver that
could fail if they changed from one version to another and the client
connected to both versions.
Also for getUDT, we need to translate type oid's into
Hi all,
as suggested from someone of you I modified the implementation,
this are the notes:
- Now the domain is stored in lower case:
[EMAIL PROTECTED] = [EMAIL PROTECTED]
but
[EMAIL PROTECTED] != [EMAIL PROTECTED];
- The order now is done by top-level-domain first:
[EMAIL PROTECTED] < [EM
Andrew Dunstan wrote:
> This is a common misconception. It ain't so. According to Eblen Moglen:
>
>
> "The claim that a GPL violation could lead to the forcing open of
> proprietary code that has wrongfully included GPL'd components is simply
> wrong. There is no provision in the Copyright Act to
[EMAIL PROTECTED] wrote:
> Imagine this scenario:
>
> OpenFoobar is released as GPL. Portions of his code are found in
> PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
> ownership of code "derived" from "his" code. There is now a valid, or
> at least legally arguable, argument
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> ... Introducing a new query execution step sounds
> like a better/easier idea than was I was going to do, which was to
> rework some of the access methods to operate on vectors instead of
> scalars. That idea looks increasingly difficult to implemen
> [EMAIL PROTECTED] wrote:
>> I'm probably just being alarmist, but think about some IP lawyer buying
>> up
>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>
> You cannot retrospectively change the terms of a license unless the
> licensee agrees to it. If something is rele
> Peter Galbavy wrote:
>
>> [EMAIL PROTECTED] wrote:
>>
>>> I'm probably just being alarmist, but think about some IP lawyer
>>> buying up
>>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>>
>>
>> You cannot retrospectively change the terms of a license unless the
>> licen
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 19 May 2004 19:34
> To: Jeffrey W. Baker
> Cc: [EMAIL PROTECTED]; Marc Fournier
> Subject: [HACKERS] search engine down (again)
>
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > If you are referring to archive
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> > Or:
> > 2. Sort AND COPY TID's into physical order.
> > 3. Read heap in phy. order, match results to un-sorted TID list.
> > That sounds quite cheap.
>
> No, it sounds like handwaving. Wh
"Glen Parker" <[EMAIL PROTECTED]> writes:
> What am I missing? Why is a performance bottle neck of this magnitude not
> on the same list of priorities as PITR, replication, and Win32?
It's higher on my personal to-do list than most of those ;-). But those
things are getting done because there ar
On Wed, 2004-05-19 at 11:56, Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > Are you saying that index scan results are sorted by something other
> > than the index key? Because in my scheme they would still be sorted by
> > index key.
>
> Not unless you add yet another sort
> Amen. plperlNG was always intended as a replacement.
In fact, one of the reasons I'm a bit sad about us rushing to feature
freeze on 1 June is that Joshua and I had hoped to get a greatly beefed
up plperl ready in time for 7.5, but I don't think we can make June 1.
I don't think we will make i
"Glen Parker" <[EMAIL PROTECTED]> writes:
>> Not unless you add yet another sort step after the fetch step, that is
>> the idea becomes
>> 1. read index to get candidate TIDs
>> 2. sort TIDs into physical order
>> 3. read heap in physical order, check row visibility
>> 4. sort selected rows into in
On Wed, 2004-05-19 at 13:10, Tom Lane wrote:
> "Glen Parker" <[EMAIL PROTECTED]> writes:
> >> Not unless you add yet another sort step after the fetch step, that is
> >> the idea becomes
> >> 1. read index to get candidate TIDs
> >> 2. sort TIDs into physical order
> >> 3. read heap in physical ord
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> No doubt, you can't just naively create giant vectors of TIDs and expect
> to sort them. Is there any concept in Pg of an unrealized result?
Only for the case of a partially-read plan result. That is, we do this
for rowsets, but not for scalars or
Tom Lane <[EMAIL PROTECTED]> writes:
> The main thing that unordered indexscan could do for us is extend the
> usefulness of indexscan plans into relatively-poor-selectivity cases
> where we presently tend to drop back to seqscans.
Well I'm sure Tom remembers this since he's mentioned it in th
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Marc G. Fournier wrote:
That is the plan ... unless someone knows a reason why they can't be
built independently of the core?
How about this one: Everything we have moved from the core to gborg so
far has been a misera
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> Sent: Wednesday, May 19, 2004 11:56 AM
> Not unless you add yet another sort step after the fetch step, that is
> the idea becomes
> 1. read index to get candidate TIDs
> 2. sort TID
Peter Galbavy wrote:
[EMAIL PROTECTED] wrote:
I'm probably just being alarmist, but think about some IP lawyer
buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.
You cannot retrospectively change the terms of a license unless the
licensee agrees to it. If something
On Wed, May 19, 2004 at 09:20:57AM +0800, Christopher Kings-Lynne wrote:
> >Seriously though, we all have the roles that we play. I don't think
> >redirecting specific resources to other
> >resources will help beyond slowing up the original resources.
>
> And now Neil's on holidays :)
Not yet I
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> For starters, read the previous discussions of this in the archives.
Search doesn't work. Even if it did, I'm not sure what I would search on.
Do you remember the time frame of the discussion?
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> Are you saying that index scan results are sorted by something other
> than the index key? Because in my scheme they would still be sorted by
> index key.
Not unless you add yet another sort step after the fetch step, that is
the idea becomes
Josh Berkus wrote:
> Tom,
>
> > > The main purpose of mini-releases would be to make testing more
> > > accessable to newbies who find anon-CVS intimidating.
> >
> > Who said anything about anon-CVS? There are the nightly snapshots
> > for those who want a tarball.
>
> Really? Where are they?
Tom,
> > The main purpose of mini-releases would be to make testing more
> > accessable to newbies who find anon-CVS intimidating.
>
> Who said anything about anon-CVS? There are the nightly snapshots
> for those who want a tarball.
Really? Where are they? I'd like to be able to refer peo
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> If you are referring to archives.postgresql.org, all I have to say is:
> "An error occured! Can not connect to search daemon"
> And as far as I have seen, it's been like that for years.
I do seem to be getting that today (Marc?) but it's hardly be
Josh Berkus wrote:
People,
So, why tie it into the PostgreSQL source tree? Won't it be popular
enough to live on its own, that it has to be distributed as part of the
core?
Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL,
as part of the core distribution -- when we
[EMAIL PROTECTED] wrote:
I'm probably just being alarmist, but think about some IP lawyer buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.
You cannot retrospectively change the terms of a license unless the
licensee agrees to it. If something is released GPL, then t
On Wed, 2004-05-19 at 07:58, Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > We have noticed a way to make a major improvement in Pg's performance on
> > our workload, and I would like to get your thoughts before I go off to
> > work up a patch.
>
> For starters, read the prev
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>> That is the plan ... unless someone knows a reason why they can't be
>> built independently of the core?
> How about this one: Everything we have moved from the core to gborg so
> far has been a miserable failure.
JDBC se
> What might be handy is an alpha build of the win32 version
> once the folks developing it feel it's stable enough to merit
> such a thing...
http://www.hagander.net/pgsql/win32snap/
Merlin has set a job up that compiles it daily.
It may be broken right this minute because of the exec stuff, b
Robert Treat wrote:
> On Wed, 2004-05-19 at 12:55, Josh Berkus wrote:
> > Tom,
> >
> > > The main downside of testing a snapshot, as I see it, is that the
> > > snapshot is virtually certain not to be initdb-compatible with either
> > > the previous release or the upcoming one. Mini-releases woul
Andrew Dunstan wrote:
> Frankly, although I am a relative newcomer around here, I am not
> convinced that "lightening the core" has been a great success, or can be
> made to be so. Certainly Peter's comments on the history to date suggest
> that a re-evaluation might be in order.
Moving stuff o
On Wed, 2004-05-19 at 12:55, Josh Berkus wrote:
> Tom,
>
> > The main downside of testing a snapshot, as I see it, is that the
> > snapshot is virtually certain not to be initdb-compatible with either
> > the previous release or the upcoming one. Mini-releases would have
> > that problem too, and
Josh Berkus wrote:
People,
So, why tie it into the PostgreSQL source tree? Won't it be popular
enough to live on its own, that it has to be distributed as part of the
core?
Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL,
as part of the core distribution --
Josh Berkus <[EMAIL PROTECTED]> writes:
> The main purpose of mini-releases would be to make testing more
> accessable to newbies who find anon-CVS intimidating.
Who said anything about anon-CVS? There are the nightly snapshots
for those who want a tarball.
regards, tom l
Tom,
> The main downside of testing a snapshot, as I see it, is that the
> snapshot is virtually certain not to be initdb-compatible with either
> the previous release or the upcoming one. Mini-releases would have
> that problem too, and so I don't really see what they add in terms of
> testabili
People,
> >So, why tie it into the PostgreSQL source tree? Won't it be popular
> >enough to live on its own, that it has to be distributed as part of the
> >core?
Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL,
as part of the core distribution -- when we are pushi
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> For starters, read the previous discussions of this in the
Tom> archives.
Tom> Two questions you should have answers to before starting to
Tom> implement, rather than after, are how to deal with locking
Tom> consideratio
Richard Huxton <[EMAIL PROTECTED]> writes:
> I'm one of those that should probably be testing early. As it stands,
> I'm subscribed to -hackers and if I downloaded a snapshot from today I
> still don't know what it is I'd be testing.
> How about a series of mini-releases (say) every 8 weeks - 7 w
Marko Karppinen <[EMAIL PROTECTED]> writes:
> I think this interaction between the locale and server_encoding is
> confusing. Is there any use case for running an incompatible mix?
In hindsight we should probably not have invented per-database encoding
selection, since it's so fragile to use in co
[EMAIL PROTECTED] wrote:
On Wednesday 19 May 2004 00:19, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create
the
impression of impropriety. The ope
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> We have noticed a way to make a major improvement in Pg's performance on
> our workload, and I would like to get your thoughts before I go off to
> work up a patch.
For starters, read the previous discussions of this in the archives.
Two questions
Richard Huxton wrote:
> >>What can be done? Well, money from Fujitsu and other companies
> >>(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit
> >>some of these bigger items, so hopefully that will move us forward
> >>in these complex areas. I am not sure what could have been done
On Wed, 19 May 2004, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > There is no such thing as "too close to feature freeze", nor has there
> > ever been in the past ... other then missing it altogether. Unless there
> > are some serious flaws in the implementation, submitting it on May 31st
Dear hackers,
after some comments and discussions, here is a proof-of-concept
demonstration of a postgresql extension infrastructure.
(1) apply the patch...
(2) ** REGENERATE CONFIGURE
sh> autoconf configure.in > configure
sh> chmod +x configure
(3) configure, compile
Hi all!
Earlier I sent a question about multi-order index scanning
(http://archives.postgresql.org/pgsql-sql/2004-04/msg00276.php).
I can solve the problem with own OPERATOR CLASSes. But this solution
increase number of my indexes exponentially. In my applicaton I have
already more then 200 indexe
Dear Thomas,
> My point is, in order to maintain a good separation of concern, I
> should not use this knowledge.
I agree.
> IMHO, there's a need for a well documented "module extension build API"
> accessible from a well known place.
Sure.
I'm not really addressing that at the moment, I'm ad
I have a fairly good understanding of how the Makefile.global etc. is
organized. My point is, in order to maintain a good separation of concern, I
should not use this knowledge.
IMHO, there's a need for a well documented "module extension build API"
accessible from a well known place. This is more
> On Wednesday 19 May 2004 00:19, [EMAIL PROTECTED] wrote:
>> > [EMAIL PROTECTED] wrote:
>> >> This makes me worried. That's the way we *used* to do things, but the
>> >> sleazy IP lawyers are looking for anything with which they can create
>> >> the
>> >> impression of impropriety. The open source
On Wednesday 19 May 2004 00:19, [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >> This makes me worried. That's the way we *used* to do things, but the
> >> sleazy IP lawyers are looking for anything with which they can create
> >> the
> >> impression of impropriety. The open source and fr
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What can be done? Well, money from Fujitsu and other companies
(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit
some of these bigger items, so hopefully that will move us forward
in these complex areas.
82 matches
Mail list logo
