On 05/18/04:20/2, Tom Lane wrote:
Hm? That functionality works for any function, whether it returns a set
or not.
Okay, then I think I found a bug:
SELECT * FROM aFunction();
Gives fcinfo-resultinfo != NULL, regardless of the type of return.
SELECT aFunction();
Gives fcinfo-resultinfo !=
James William Pye [EMAIL PROTECTED] writes:
SELECT aFunction();
Gives fcinfo-resultinfo != NULL, ONLY IF it is a SRF.(fn_retset != 0)
Indeed. Since passing a ReturnSetInfo in resultinfo occurs only when
the system is expecting a set result (and is prepared to handle one),
I do not see what you
Bruce Momjian [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
Well, the point of having an infrastructure if extensions cannot rely it
being there when needed is not clear to me.
Agreed. If we are pushing things out, it seems it is our duty to make
it easy for outside things to integrate and
Tom Lane wrote:
Joseph Shraibman [EMAIL PROTECTED] writes:
Neil Conway wrote:
PostgreSQL ( 7.5) won't consider using an indexscan when the predicate
involves an integer literal and the column datatype is int2 or int8.
Is this fixed for 7.5? It isn't checked off on the TODO list at
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.
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your
Hi folks
Several times I killed clients which issued a longtime query. The
clients don't cancel the query and closes the connection. The backend
ignores the delivered SIGPIPE instead of counting it as a cancelation
request like SIGINT/TERM.
Bastian
--
Earth -- mother of the most beautiful
Hi,
Where can I find information about the trigger execution
model of postgresql ? In particular I want to know how triggers are fired when
an update happens in the database. Is the trigger evaluation and firing part of
transaction ? Please let me know where I can find more information
Nikola Milutinovic wrote:
+ #define NAN DBL_INFINITY
The compilation has went smoothly, I'll try to run regression tests.
Will let you know if something fails.
Hate to reply to myself, but here goes.
With NAN defined as DBL_INFINITY I get 3 failed regression test, most
notably float8 test.
After a long battle with technology, [EMAIL PROTECTED] (Magnus Hagander), an
earthling, wrote:
2) Pick upt he default OS timezone. This still need a little bit more
work. But the code as it stands on Win32 will give you GMT on startup
unless you specify a TZ in postgresql.conf. On Unix, it
One of the comments I saw over the past few days on how to make things on
pgFoundry more visible was to have the commit messages for its projects
sent out through pgsql-committers as well ...
How many objections would there be to setting this up, and seeing how it
works? The idea would be to
Oliver Jowett [EMAIL PROTECTED] writes:
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
Your timezone testing will have to wait for the unix timezone code to be
added in a few days.
It is strange you are having this problem with finfo only in pg_dump
because it is used a lot in the backend. Looking at the warning, it
looks like it doesn't like that 'static' specification. If you
Chris Browne [EMAIL PROTECTED] writes:
CUT0 may be _equivalent_ to GMT, but PostgreSQL isn't aware of it as
such, so inserts into the table epp_whois_cachemgr were failing with
much the same error message shown below:
It will probably be more practical to fix this after Magnus' timezone
patch
Bastian Blank [EMAIL PROTECTED] writes:
Several times I killed clients which issued a longtime query. The
clients don't cancel the query and closes the connection. The backend
ignores the delivered SIGPIPE instead of counting it as a cancelation
request like SIGINT/TERM.
That's intentional.
Bruce Momjian [EMAIL PROTECTED] writes:
It is strange you are having this problem with finfo only in pg_dump
because it is used a lot in the backend.
Yeah, but the other places are local variable names and so don't
conflict with a global function name.
regards, tom lane
[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 that
On Thursday 13 May 2004 10:01 am, shiva chetan wrote:
Where can I find information about the trigger execution model of
postgresql ? In particular I want to know how triggers are fired when an
update happens in the database. Is the trigger evaluation and firing part
of
On Thu, 20 May 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
One of the comments I saw over the past few days on how to make things on
pgFoundry more visible was to have the commit messages for its projects
sent out through pgsql-committers as well ...
How many
Marc,
what is wrong with the nightly snapshots that are created?
Nothing. I was just clueless that this was set up.
So, the 2nd step is to find a likely victi^H^H^H^Holunteer to coordinate
platform/feature testing among our large population of mailing list users.
Easier said than done
Tom Lane wrote:
BTW, while you're messing with it, can you fix the random one-character
lossage that so frequently happens in the list of file names?
While we're asking for improvements to pgsql-committers, would it be
possible for you to make it easier to view the diff for a particular
CVS
On Thu, 20 May 2004, Neil Conway wrote:
Tom Lane wrote:
BTW, while you're messing with it, can you fix the random one-character
lossage that so frequently happens in the list of file names?
While we're asking for improvements to pgsql-committers, would it be
possible for you to make it
[ Will apply with adjustment, removing tablespaces.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Marc G. Fournier wrote:
I can't see this really being possible ... have you seen this on another
project?
Sure, it's quite common. There's a list of scripts that support this
kind of functionality at the bottom of this page:
http://www.badgers-in-foil.co.uk/projects/cvsspam/
So there are plenty
On Thu, 20 May 2004, Neil Conway wrote:
Personally I'd prefer the entire diff to be attached to each -committers
mail, which would circumvent this problem. Would others find that
objectionable?
I would really like that. It'd be a lot easier to see what's going on.
Jon
On Wed, May 19, 2004 at 15:17:01 +0200,
Atesz [EMAIL PROTECTED] wrote:
I'd like to ask why the index scaning can't move on an index in
multi-order directions (For exapmle: 1.column: forward, 2.column:
backward and 3.column: forward again)? So I wouldn't have to use so many
indexes. Has
On Thu, May 20, 2004 at 08:07:34PM +, Jon Jensen wrote:
On Thu, 20 May 2004, Neil Conway wrote:
Personally I'd prefer the entire diff to be attached to each -committers
mail, which would circumvent this problem. Would others find that
objectionable?
I would really like that. It'd
On Thu, 20 May 2004, Neil Conway wrote:
Marc G. Fournier wrote:
I can't see this really being possible ... have you seen this on another
project?
Sure, it's quite common. There's a list of scripts that support this
kind of functionality at the bottom of this page:
Marc G. Fournier wrote:
Personally I'd prefer the entire diff to be attached to each -committers
mail, which would circumvent this problem. Would others find that
objectionable?
'k, let me look into it when I get back ... but some of those diffs would
be humongous, no? Ah well, let me look,
On Thu, 20 May 2004, Bruno Wolff III wrote:
On Wed, May 19, 2004 at 15:17:01 +0200,
Atesz [EMAIL PROTECTED] wrote:
I'd like to ask why the index scaning can't move on an index in
multi-order directions (For exapmle: 1.column: forward, 2.column:
backward and 3.column: forward again)?
Neil Conway wrote:
Personally I'd prefer the entire diff to be attached to each -committers
mail, which would circumvent this problem. Would others find that
objectionable?
Not me -- I have often wished for exactly that myself.
Joe
---(end of
Neil Conway [EMAIL PROTECTED] writes:
Personally I'd prefer the entire diff to be attached to each -committers
mail, which would circumvent this problem. Would others find that
objectionable?
Yes --- way too bulky, not to mention it turns the list archive into a
duplicate of the CVS store.
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Personally I'd prefer the entire diff to be attached to each -committers
mail, which would circumvent this problem. Would others find that
objectionable?
Yes --- way too bulky, not to mention it turns the list archive into a
Bruce Momjian wrote:
Agreed, even if the URL is only valid for a week or so.
Why would the URL only be temporarily valid?
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
Neil Conway wrote:
Bruce Momjian wrote:
Agreed, even if the URL is only valid for a week or so.
Why would the URL only be temporarily valid?
If Marc needed to save disk space or something. If we could
auto-generate on the fly via a URL, even better.
--
Bruce Momjian
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
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
On Thu, 20 May 2004, Bruce Momjian wrote:
Neil Conway wrote:
Bruce Momjian wrote:
Agreed, even if the URL is only valid for a week or so.
Why would the URL only be temporarily valid?
If Marc needed to save disk space or something. If we could
auto-generate on the fly via a URL, even
k, hasn't come through yet, but looked in the archives and the message
looks good ... missed a / for cvsweb, so fixed that ...
the Subject line uses the first line of the log message (up to the first .
or 72 characters, so the subjects can actually tell a message in itself if
you build your log
On Thu, May 20, 2004 at 06:07:15PM -0400, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Personally I'd prefer the entire diff to be attached to each -committers
mail, which would circumvent this problem. Would others find that
objectionable?
Yes --- way too bulky, not to
Not sure if I like the URLs, myself ... opinions?
On Thu, 20 May 2004, PostgreSQL Daemon wrote:
Log Message:
---
attempt at a multi file commit, to seee how it formats
Modified Files:
--
pgsql-server/contrib:
README
Marc G. Fournier wrote:
k, hasn't come through yet, but looked in the archives and the message
looks good ... missed a / for cvsweb, so fixed that ...
Looks good, but one minor quibble: the URL is to the cvsweb page for the
file in question, not the diff for the change to the file described by
Bruce Momjian wrote:
Neil Conway wrote:
Bruce Momjian wrote:
Agreed, even if the URL is only valid for a week or so.
Why would the URL only be temporarily valid?
If Marc needed to save disk space or something. If we could
auto-generate on the fly via a URL, even better.
Neil Conway [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
k, hasn't come through yet, but looked in the archives and the message
looks good ... missed a / for cvsweb, so fixed that ...
Looks good, but one minor quibble: the URL is to the cvsweb page for the
file in question, not the
On Thu, 20 May 2004, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
k, hasn't come through yet, but looked in the archives and the message
looks good ... missed a / for cvsweb, so fixed that ...
Looks good, but one minor quibble: the URL is to the cvsweb
Nope, was wrong ... adding the -V does add teh revision to the end of the
URL ...
On Thu, 20 May 2004, Marc G. Fournier wrote:
On Thu, 20 May 2004, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
k, hasn't come through yet, but looked in the archives and
On Thu, 20 May 2004, Neil Conway wrote:
Marc G. Fournier wrote:
k, hasn't come through yet, but looked in the archives and the message
looks good ... missed a / for cvsweb, so fixed that ...
Looks good, but one minor quibble: the URL is to the cvsweb page for the
file in question, not the
Marc G. Fournier wrote:
Not sure if I like the URLs, myself ... opinions?
You could try cvsspam, which is what I use in-house. Neil
posted the URL. It does HTML mail, so it'd probably belong
on a dedicated list. It's a huge help with the links,
though, see this sample:
Greg Copeland wrote:
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
fact that checkpoints, vacuum runs and pg_dumps bog down their machines
to the state where simple queries take several seconds care that much
for any Win32 port?
Hi,
Not sure if I like the URLs, myself ... opinions?
All those links look messy IMHO. Maybe it's possible to give one link for
every directory instead one for every file?
Something like:
Log Message:
---
attempt at a multi file commit, to seee how it formats
Modified Files:
'k, let me look into it when I get back ... but some of those diffs would
be humongous, no? Ah well, let me look, I can try it out and if nobody
likes it, can always disable the diffs again afterwards ...
Showing diffs will also allow more eyes to find little bugs in the patches.
Chris
Not sure if I like the URLs, myself ... opinions?
Can the urls point to the exact diff?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
On Fri, 21 May 2004, Christopher Kings-Lynne wrote:
Not sure if I like the URLs, myself ... opinions?
Can the urls point to the exact diff?
Already fixed for that ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!:
Not sure if I like the URLs, myself ... opinions?
Can the urls point to the exact diff?
Already fixed for that ...
Yeah sorry - i hate reading this conversations in a later timezone :( I
really should have learned by now :/
Chris
---(end of
Sander Steffann wrote:
All those links look messy IMHO. Maybe it's possible to give one link for
every directory instead one for every file?
The commit message ought to (and how does) contain a link directly to
the relevant diff, rather than to the cvsweb entry for the modified
file. Emitting
Andrew Dunstan wrote:
Why would the URL only be temporarily valid?
If Marc needed to save disk space or something. If we could
auto-generate on the fly via a URL, even better.
That's what cvsweb does ... it will generate a diff between any 2
arbitrary versions of a file on the
I am leaving on Friday for a 2-day camping trip and will obviously be
out of email contact.
I will keep the patches in the patch queue until I return on Sunday.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your
On Thu, 20 May 2004, Bruce Momjian wrote:
Andrew Dunstan wrote:
Why would the URL only be temporarily valid?
If Marc needed to save disk space or something. If we could
auto-generate on the fly via a URL, even better.
That's what cvsweb does ... it will generate a diff
Marc G. Fournier wrote:
On Thu, 20 May 2004, Bruce Momjian wrote:
My point is that for any non-trivial patch, you need to see all the
files modified in a single view, rather than poke around to see
different changes made to different files.
Tom appears to be against, everyone else seems to be for
On Thu, 20 May 2004, Joe Conway wrote:
Marc G. Fournier wrote:
On Thu, 20 May 2004, Bruce Momjian wrote:
My point is that for any non-trivial patch, you need to see all the
files modified in a single view, rather than poke around to see
different changes made to different files.
Tom
On Wed, 2004-05-19 at 12:55, Tom Lane wrote:
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
Tom Lane wrote:
Nikola Milutinovic [EMAIL PROTECTED] writes:
[ about NaN on Tru64 ]
This compiles on Tru64 4.0D (the compiler swallows it), but fails on
Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file
complaining on that constant evaluation. The best way to solve it is to
Marc G. Fournier [EMAIL PROTECTED] writes:
I can enable the diff attachment for commit messages ... I just fear the
size of the email going out for some of the large patches that are applied
That's my problem too. Someone suggested creating two mail lists, one
non-archived with the full diffs
On Fri, 21 May 2004, Neil Conway wrote:
Marc G. Fournier wrote:
Tom appears to be against, everyone else seems to be for ... should we try
it and see how it works out?
Sure, although I personally think Andrew's suggestion of creating a
separate (non-archived) list that includes the full
Marc G. Fournier wrote:
Tom appears to be against, everyone else seems to be for ... should we try
it and see how it works out?
Sure, although I personally think Andrew's suggestion of creating a
separate (non-archived) list that includes the full diff is the best
solution. That satisfies both
63 matches
Mail list logo
