The function current_setting returns 'unset' if a parameter is not set.
Should it not return null? This is not documented, so I guess this just
arose out of the implementation, or is this intentional?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
I had a further thought about this. What we're really talking about
here is a reference-counted TupleDesc structure: it's got no necessary
connection to TypeCacheEntry at all. And in fact there are other places
in the system that could use such a facility. For instance,
TupleTableSlot has a
Peter Eisentraut [EMAIL PROTECTED] writes:
The function current_setting returns 'unset' if a parameter is not set.
Should it not return null? This is not documented, so I guess this just
arose out of the implementation, or is this intentional?
That's because SHOW does the same thing. SHOW
Am Dienstag, 10. Januar 2006 16:01 schrieb Tom Lane:
That's because SHOW does the same thing. SHOW has a little problem in
that it can't readily show the difference between null and an empty
string, so while I find the behavior pretty ugly, I don't have a better
idea.
Since SHOW is primarily
On Tue, 2006-01-10 at 09:47 -0500, Tom Lane wrote:
I had a further thought about this. What we're really talking about
here is a reference-counted TupleDesc structure: it's got no necessary
connection to TypeCacheEntry at all.
Yeah, I came to basically the same conclusion when implementing
Peter Eisentraut wrote:
The function current_setting returns 'unset' if a parameter is not
set.
This is not documented,
It is documented to produce equivalent output as the sql SHOW command.
Although the reference page for SHOW does not specifically address
parameters that are not set, it
Hi,
I just noticed today that Postgresql accepts a value of 24:00:00, this
is for sure not correct as there is no such thing as 24:00:00
PG Admin III will display this value just fine which is also incorrect,
PG Lightning Admin catches it as a invalid time, but shouldn't there be
some
Tony Caduto wrote:
Hi,
I just noticed today that Postgresql accepts a value of 24:00:00, this
is for sure not correct as there is no such thing as 24:00:00
PG Admin III will display this value just fine which is also incorrect,
PG Lightning Admin catches it as a invalid time, but
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Caduto
Sent: 10 January 2006 15:38
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Question about Postgresql time fields(possible bug)
Hi,
I just noticed today that Postgresql accepts a
Peter Eisentraut [EMAIL PROTECTED] writes:
Moreover, the unset state shouldn't exist at all. No parameter can behave
reasonably if unset behaved differently from an empty string. Explicitly
assigning an unset state doesn't work. So it seems that for all external
communication, an unset
In article [EMAIL PROTECTED],
Bruce Momjian pgman@candle.pha.pa.us writes:
Tony Caduto wrote:
Hi,
I just noticed today that Postgresql accepts a value of 24:00:00, this
is for sure not correct as there is no such thing as 24:00:00
PG Admin III will display this value just fine which is
Harald Fuchs [EMAIL PROTECTED] writes:
Bruce Momjian pgman@candle.pha.pa.us writes:
A leap second will show as 24:00:00. It is a valid time.
Shouldn't such a leap second be represented as '... 23:59:60'?
People who didn't like 24:00:00 would complain about that, too ;-)
Actually, my
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harald Fuchs
Sent: 10 January 2006 16:53
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Question about Postgresql time
fields(possible bug)
In article [EMAIL PROTECTED],
Bruce Momjian
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
Harald Fuchs [EMAIL PROTECTED] writes:
Bruce Momjian pgman@candle.pha.pa.us writes:
A leap second will show as 24:00:00. It is a valid time.
Shouldn't such a leap second be represented as '... 23:59:60'?
People who didn't
On Mon, 2006-01-09 at 22:08 -0500, Greg Stark wrote:
So it's not the 8k block reading that's fooling Linux into reading ahead 32k.
It seems 32k readahead is the default for Linux, or perhaps it's the
sequential access pattern that's triggering it.
Nah, Linux 2.6 uses flexible readahead logic.
On 10/1/06 18:00, Tony Caduto [EMAIL PROTECTED] wrote:
Dave Page wrote:
On looking further it appears to me that 24:00:00 is not a leap second
(which definitely can be 23:50:60), but just another way of expressing
midnight.
From: http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Tony, Dave,
That's not really the point. The ISO 8601 standard allows midnight to be
expressed as 00:00:00 or 24:00:00 to enable you to tell which midnight
is being referred to (ie. The beginning or the end of the day).
IIRC, the reason for supporting 24:00:00 is that some popular client
Dave Page dpage@vale-housing.co.uk writes:
That's not really the point. The ISO 8601 standard allows midnight to be
expressed as 00:00:00 or 24:00:00 to enable you to tell which midnight is
being referred to (ie. The beginning or the end of the day).
There are other reasons for allowing it
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-01-09 at 22:08 -0500, Greg Stark wrote:
So it's not the 8k block reading that's fooling Linux into reading ahead
32k.
It seems 32k readahead is the default for Linux, or perhaps it's the
sequential access pattern that's triggering
On 1/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I've been working with SQL Server for a long time and many times I had to
change how an index page is filled with fillfactor clause. I've noticed that
PostgreSQL doesn't have anything like that, am I right?
I'd like to implement
FWIW, results from a FBSD6.0 box. Between every run I ran code to zero
800MB (out of 1G) of memory, which should have effectively flushed the
OS cache (it would just put the OS into swapping).
Reading 1% (1280/128000 blocks 1048576000 bytes) total time 6870595us
MB/s 1.53 effective MB/s 152.62
Hi,
Just for curiosity: suppose there is an excellent index frequently picked by
the optimizer. Suppose now that this index became extremelly fragmented with
thousands of updates. Without a REINDEX, will Optimizer still pick it? Or the
optimizer is smart enough to detect index fragmentation and
I just ran cvs update in my 8.1 source tree and it took nearly
25 minutes to complete; it usually takes about 30-60 seconds. Is
anybody else seeing problems?
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will
On Tue, Jan 10, 2006 at 07:44:23PM -0700, Michael Fuhr wrote:
I just ran cvs update in my 8.1 source tree and it took nearly
25 minutes to complete; it usually takes about 30-60 seconds. Is
anybody else seeing problems?
I forgot to mention that this is anonymous cvs (anoncvs.postgresql.org).
On Tue, 10 Jan 2006, Michael Fuhr wrote:
On Tue, Jan 10, 2006 at 07:44:23PM -0700, Michael Fuhr wrote:
I just ran cvs update in my 8.1 source tree and it took nearly
25 minutes to complete; it usually takes about 30-60 seconds. Is
anybody else seeing problems?
I forgot to mention that this
That's not really the point. The ISO 8601 standard allows midnight to be
expressed as 00:00:00 or 24:00:00 to enable you to tell which midnight is
being referred to (ie. The beginning or the end of the day).
PostgreSQL allows you to make use of that part of the standard, and as admin
tool
[EMAIL PROTECTED] writes:
Just for curiosity: suppose there is an excellent index frequently picked by
the optimizer. Suppose now that this index became extremelly fragmented with
thousands of updates. Without a REINDEX, will Optimizer still pick it? Or the
optimizer is smart enough to detect
While thinking about how to do memory management for the TupleDesc
refcounting changes, it occurred to me that this coding pattern is
dangerous:
local_var = MemoryContextAlloc(TopMemoryContext, ...);
func_call();
/* ... */
/* update global state */
if (global != NULL)
pfree(global);
global =
Neil Conway [EMAIL PROTECTED] writes:
Thoughts?
One comment is that there are worse things than small memory leaks in
seldom-followed code paths, especially if those paths are only taken in
error cases. I'm interested in fixing this if it can be done without
unreasonable code complication, but
29 matches
Mail list logo
