-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 01 April 2003 20:59
To: Robert Treat
Cc: Peter Eisentraut; Dave Page; [EMAIL PROTECTED]
Subject: Re: [HACKERS] View definition formatting
We could make variants of pg_get_ruledef etc. that
pretty-print,
mlw kirjutas T, 01.04.2003 kell 15:29:
Hannu Krosing wrote:
[EMAIL PROTECTED] kirjutas E, 31.03.2003 kell 19:52:
Actually, as far as I am aware, the header is for metadata, i.e. it is the
place to describe the data being returned.
Did you read the SOAP spec ?
yes
???
Hannu Krosing wrote:
mlw kirjutas T, 01.04.2003 kell 15:29:
Hannu Krosing wrote:
[EMAIL PROTECTED] kirjutas E, 31.03.2003 kell 19:52:
Actually, as far as I am aware, the header is for metadata, i.e. it is the
place to describe the data being returned.
Did you read
hi,
does anybody know anything about mariposa
(http://s2k-ftp.cs.berkeley.edu:8000/mariposa/index.html)?
why did they stop the project?
is there anywhere an intel compatible version?
i'm interested in such a system and thinking about developing something
like this.
thanks,
moritz
--
On Mon, 31 Mar 2003, Peter Eisentraut wrote:
Tom Lane writes:
Serializable or not, there is a good case for saying that cursors don't
see changes made after they are opened, period.
No one disputes that insensitive cursors are a valid concept. But this
discussion is about updating
Gavin Sherry [EMAIL PROTECTED] writes:
Regardless of which, we could insert a special case in ExecutePlan() (or
somewhere more appropriate?) to test that the tuple returned from the
lower level ExecTidScan() still satisifies the cursor query. It should be
sufficient to use HeapTupleSatisfies()
Thanks for the replies of Tom, Bruce, Justin, and Peter
regarding my posts and personal emails.
Just wants to provide some updates -
Summary of issues:
1. I was asked to tune a production database on client's AIX4.3.3 -
it's Postgresql 7.3.1, I can vacuum full,
but can't do analyze (hanging); it
TRY TEST WIN32 PORT. DATABASE GO BOOM! TRY FIX NOBODY CARE. WIN32
PORT COME OUT MANY DATABASE GO BOOM! TRY HELP GET IGNORED. JUST WANT
HELP. BUG FIX?
Regards,
Merlin
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to
On Tue, Apr 01, 2003 at 11:24:01AM -0500, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
This isn't really an issue for 64 bit hardware is it?
Is int 64 bits on such a machine? The ones I've dealt with chose to
It was for the regression tests we did recently on a 64-bit
Andreas Pflug [EMAIL PROTECTED] writes:
If your kernel isn't V6 enabled, the incoming socket will be AF_INET,
and no conversion is done, that's why you don't get the problem.
To fix this, the [12]..[15] indices need to be reversed (for Intel).
I've applied a patch to fix this, but can't try
Merlin Moncure wrote:
TRY TEST WIN32 PORT. DATABASE GO BOOM! TRY FIX NOBODY CARE. WIN32
PORT COME OUT MANY DATABASE GO BOOM! TRY HELP GET IGNORED. JUST WANT
HELP. BUG FIX?
Pardonne moi?
What exactly did you test? If it is the PeerDirect Beta version of
PostgreSQL for Windows named
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
Basically, one should only turn this variable on after giving up on the
possibility of getting any data out of the broken page itself. It would
be folly to run with it turned on as a normal setting.
This statement should *definitely* go
On Wed, Apr 02, 2003 at 03:25:58PM -0500, Tom Lane wrote:
the current session. This is kind of an ugly wart on the GUC mechanism,
but I think not difficult to do with an assign_hook (it just has to
refuse non-interactive settings).
It may be an ugly wart, but I think it's only prudent. I'd
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
Basically, one should only turn this variable on after giving up on the
possibility of getting any data out of the broken page itself. It would
be folly to run with it turned on as a normal setting.
This statement
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Perhaps better would be to throw a message message any time it is turned
on, reminding them it should not be left on. Is that cleaner?
Where are you going to throw a message to, if it's in postgresql.conf?
Bleating in the
Andrew Sullivan [EMAIL PROTECTED] writes:
On Wed, Apr 02, 2003 at 03:25:58PM -0500, Tom Lane wrote:
the current session. This is kind of an ugly wart on the GUC mechanism,
but I think not difficult to do with an assign_hook (it just has to
refuse non-interactive settings).
It may be
Kevin Brown [EMAIL PROTECTED] writes:
Hmm...I don't know that I'd want to go that far -- setting this
variable could be regarded as a policy decision. Some shops may have
very good reason for running with ZERO_DAMAGED_PAGES enabled all the
time, but I don't know what those reasons might be.
Hey Guys,
Sorry if this should go to another list, but I was looking over the
TODO list for something small I could cut my teeth on and noticed
you have the following listed in the TODO in the 'Source Code'
section:
* Add --port flag to regression tests
And based
Andrew Dunstan writes:
If the intention is to use field names as (local) tag names, how will you
handle the case where the field name isn't a valid XML name? Of course, one
could do some sort of mapping (replace illegal chars with _, for example)
but then you can't be 100% certain that you
mlw writes:
That function looks great, but what happens if you need to return 1
million records?
The same thing that happens with any set-returning function: memory
exhaustion.
I have an actual libpq program which performs a query against a server,
and will stream out the XML, so the number
Jan Wieck wrote:
What exactly did you test? If it is the PeerDirect Beta version of
PostgreSQL for Windows named UltraSQL, please know that thus far there
has to my knowledge not been an offical, supported release of UltraSQL
yet - and since the company eliminated the group working on that
mlw kirjutas K, 02.04.2003 kell 15:56:
Hannu Krosing wrote:
What you have come up with _is_not_ a SOAP v1.1 message at all. It does
use some elements with similar names but from different namespace.
the SOAP Envelope, Header and Body elemants must be from namespace
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.
My SOAP/XML function will probably require my LGPL library as there is a
lot of code I
Hannu Krosing wrote:
mlw kirjutas K, 02.04.2003 kell 15:56:
Hannu Krosing wrote:
What you have come up with _is_not_ a SOAP v1.1 message at all. It does
use some elements with similar names but from different namespace.
the SOAP Envelope, Header and Body elemants must be from namespace
On Wed, 2 Apr 2003, mlw wrote:
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.
My SOAP/XML function will probably require my LGPL
On Wed, 2 Apr 2003, mlw wrote:
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.
My SOAP/XML function will probably
On Wed, 2 Apr 2003, Marc G. Fournier wrote:
On Wed, 2 Apr 2003, mlw wrote:
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.
mlw writes:
I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?
No, the point is, why put it in contrib when someone who wants to use it
has to download your library anyway. Then you might as well distribute
the module next to that
On Wed, 2 Apr 2003, scott.marlowe wrote:
If that is a real objective, I'm surprised.
The base source tree has always been as BSD pure as we can make it ... its
never been kept a secret ...
True. But not linking to LGPLd libs would be a bit extreme there.
Correct, we've always had
mlw wrote:
I think you are interpreting the spec a bit too restrictively. The
syntax is fairly rigid, but the spec has a great degree of flexibility.
I agree that, syntactically, it must work through a parser, but there is
lots of room to be flexible.
This is /exactly/ the standard problem
[snip]
a program in /contrib linking to an LGPL lib has never been
an issue.
Linking to LGPL libs doesn't encumber the software linking to it.
If that is a real objective, I'm surprised.
The base source tree has always been as BSD pure as we can
make it ...
its never been kept
On Wed, 2003-04-02 at 18:00, Marc G. Fournier wrote:
On Wed, 2 Apr 2003, scott.marlowe wrote:
True. But not linking to LGPLd libs would be a bit extreme there.
Correct, we've always had libreadline support, as a compile option
Why is that relevant? libreadline is GPL'd, not LGPL'd.
Last month's discussions about a revised FE/BE protocol make it clear that
there is usefulness in breaking down the query-processing cycle and making
individual steps available at the protocol level. This surfaced in
several forms in the discussion, including requests for protocol-level
PREPARE
mlw [EMAIL PROTECTED] writes:
Tom Lane wrote:
If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.
I'm a little put off by this attitude, are you saying there are
On Wednesday 02 April 2003 18:11, Dann Corbit wrote:
[snip]
True. But not linking to LGPLd libs would be a bit extreme there.
I disagree. Because of the language in the LGPL:
http://www.gnu.org/copyleft/lesser.txt
I would not use LGPL tools in any finished commercial project. For me,
if
On Wed, 2 Apr 2003, Lamar Owen wrote:
On Wednesday 02 April 2003 18:11, Dann Corbit wrote:
[snip]
True. But not linking to LGPLd libs would be a bit extreme there.
I disagree. Because of the language in the LGPL:
http://www.gnu.org/copyleft/lesser.txt
I would not use LGPL tools
On Wed, Apr 02, 2003 at 02:07:02PM -0700, Jason Earl wrote:
There are some cases where this particular feature would be useful.
What needs to be done is to make the feature less dangerous to the
newbie without making it less useful to the person who actually needs
the functionality.
I'll
Lamar Owen [EMAIL PROTECTED] writes:
stifles ROTFL
Everyone does realize that on Linux PostgreSQL binaries link against glibc,
which is LGPL..
And your point is?
On other Unixoid systems you can link against BSD-license libc code, or
some-random-proprietary-license code from HP or Sun
Tom Lane wrote:
Andrew Sullivan [EMAIL PROTECTED] writes:
You know you have big-trouble, oh-no, ISP ran over
the tapes while they were busy pitching magnets through your cage,
data corruption problems, and this is your best hope for recovery?
Great. Log in, turn on this option, and
What I'd really prefer to see is not a ZERO_DAMAGED_PAGES setting,
but an explicit command to DESTROY PAGE n OF TABLE foo. That would
make you manually admit defeat for each individual page before it'd
drop data. But I don't presently have time to implement such a command
(any volunteers
On Wed, Apr 02, 2003 at 11:10:13PM -0500, Tom Lane wrote:
What I'd really prefer to see is not a ZERO_DAMAGED_PAGES setting,
but an explicit command to DESTROY PAGE n OF TABLE foo. That would
make you manually admit defeat for each individual page before it'd
drop data. But I don't
Andrew Sullivan [EMAIL PROTECTED] writes:
You know you have big-trouble, oh-no, ISP ran over
the tapes while they were busy pitching magnets through your cage,
data corruption problems, and this is your best hope for recovery?
Great. Log in, turn on this option, and start working. But
Alvaro Herrera [EMAIL PROTECTED] writes:
Huh, and what if I accidentaly mistype the number and destroy a valid
page? Maybe the command should only succeed if it confirms that the
page is corrupted.
Good point ... but what if the corruption is subtle enough that the
automatic tests don't
On Wednesday 02 April 2003 22:39, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
stifles ROTFL
Everyone does realize that on Linux PostgreSQL binaries link against
glibc, which is LGPL..
And your point is?
That everyone is being entirely too picky. Hey, we link against other
Lamar Owen [EMAIL PROTECTED] writes:
And your point is?
That everyone is being entirely too picky. Hey, we link against other
things, too. Some aren't LGPL. The readline example is a good one,
incidentally: it's GPL.
Yeah, it's an excellent example: there is an alternative implementation
On Wednesday 02 April 2003 21:59, Stephan Szabo wrote:
On Wed, 2 Apr 2003, Lamar Owen wrote:
However, linking a work that uses the Library with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a work that
On Thursday 03 April 2003 00:04, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
And its stubs are in the backend, of all places.
Really? I must have missed that.
On Linux as compiled in Red Hat 9, at least:
[EMAIL PROTECTED] lowen]$ ldd /usr/bin/postgres
libpam.so.0 =
Looks like Tom just checked a fix into CVS for your reported problem.
Would you please test it?
---
Andreas Pflug wrote:
Ok Bruce,
I found out what's happening.
I'm running a Suse 8.1 2.4.19 standard kernel which has
OK, I have removed the TODO item. Thanks.
---
Frank Wiles wrote:
Hey Guys,
Sorry if this should go to another list, but I was looking over the
TODO list for something small I could cut my teeth on and
Jan Wieck wrote:
Merlin Moncure wrote:
TRY TEST WIN32 PORT. DATABASE GO BOOM! TRY FIX NOBODY CARE. WIN32
PORT COME OUT MANY DATABASE GO BOOM! TRY HELP GET IGNORED. JUST WANT
HELP. BUG FIX?
Pardonne moi?
What exactly did you test? If it is the PeerDirect Beta version of
50 matches
Mail list logo
