Tom Lane wrote:
> "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> > troels=# create table lookat_feature(
> > troels(# feature_id char(4),
> > troels(# status varchar(2) default 'TODO'
> > troels(# );
> > CREATE TABLE
> > troels=# alter table lookat_feature
> > troels-# alter column stat
On Fri, 2004-10-22 at 07:54, Simon Riggs wrote:
> If I could go further, I'd like to add this as an option on the command if
> possible, rather than a presumption that all such statements should not be
> logged.
Why is that necessary?
-Neil
---(end of broadcast)
Tom Lane wrote:
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> > On Thu, 21 Oct 2004, Tom Lane wrote:
> >> It was suggested to me off-list that libpq should do
> >> "fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
> >> This would prevent any child program from accidentally
On Sunday night, we're going to be looking at rolling up beta4, so that
everyone is working with 'the same copy' as far as all of the changes that
have gone in over the past couple of weeks.
If anyone has any outstanding bug reports, or patches, that haven't been
addressed yet, please submit th
> Gavin Sherry
> Just thinking of optimisations, I wonder if it would be possible to bypass
> WAL (like we do for ALTER TABLE ... SET TABLESPACE) if archiving is
> disabled, and fsync the newly created relfilenode after the data is
inserted.
>
Yes please. This is good for Data Warehousing ELT-sty
Stephan Szabo <[EMAIL PROTECTED]> writes:
> While not exactly what the spec invisions, I believe we can come
> closer to the correct behavior by treating all of the referential actions
> as non-deferrable while allowing deferment of NO ACTION and the check
> itself.
Since no one seems to hav
On Tue, Oct 19, 2004 at 07:38:49PM -0300, Alvaro Herrera wrote:
> Huh, you are wrong. At least btree does index null values, and one
> other index method does too. The other two index methods don't. What
> doesn't work is using an index with the IS NULL construct, because it's
> not an operator.
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Thu, 21 Oct 2004, Tom Lane wrote:
>> It was suggested to me off-list that libpq should do
>> "fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
>> This would prevent any child program from accidentally or maliciously
>> interfe
On Thu, 21 Oct 2004, Tom Lane wrote:
> It was suggested to me off-list that libpq should do
> "fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
> This would prevent any child program from accidentally or maliciously
> interfering with the connection.
Either way that the lib
It was suggested to me off-list that libpq should do
"fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
This would prevent any child program from accidentally or maliciously
interfering with the connection. It would also prevent people from
deliberately turning over a connect
I'm thinking that this subject has some cross-overs with another topic
mentioned recently: improving VACUUM performance.
Just to recap: Frequently updated tables are a problem because they grow
significantly, with many useless row versions in there. The usual
solution is to run frequent VACUUMs o
Jim,
> Yes, but using overloading to implement defaults is a pain. Imagine how
> much you need to overload to have 5 default arguments; that equates to 4
> stub functions/prodecudes. In the case of adding a single parameter it's
> not that bad, but it becomes very onerous if you're trying to provi
On Thu, 21 Oct 2004, Tom Lane wrote:
> > Would it be possible to check the compatibility of a default value for
> > the associated column?
>
> I think that would introduce as many problems as it would fix. AFAICS
> the only way to make such a check is to evaluate the expression and see
> what ha
On Wed, Oct 06, 2004 at 09:17:23PM -0700, Josh Berkus wrote:
> And, not that I think about it, I have a way to support DEFAULT params within
> the context of overloading. Let me muse it over and I'll get back to you.
Yes, but using overloading to implement defaults is a pain. Imagine how
much y
Chris, Manfred, David, "Mohawk",
> > What about a dblink style interface to a non-MVCC SQL database? ÂI
> > think someone on this list mentioned that there are open source
> > in-memory SQL databases.
>
> Funny you should mention this. ÂI'm working on a generalized one that
> uses PL/PerlU at
The
On Thu, 21 Oct 2004, Tom Lane wrote:
> > I've made a partial implementation of a datatype "timestamp with time
> > zone" as described in the sql standard. The current type "timestamptz"
> > does not store the time zone as a standard one should do.
>
> I'm aware that there are aspects of the spe
Troels Arvin <[EMAIL PROTECTED]> writes:
> On Wed, 20 Oct 2004 14:07:29 -0400, Tom Lane wrote:
>> Hmm. What's going on here is that the stored default expression is
>> actually of the form
>> ('TODO'::varchar)::varchar(2)
> Would it be possible to check the compatibility of a default value for
>
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> I've made a partial implementation of a datatype "timestamp with time
> zone" as described in the sql standard. The current type "timestamptz"
> does not store the time zone as a standard one should do.
I'm aware that there are aspects of the spec b
I've made a partial implementation of a datatype "timestamp with time
zone" as described in the sql standard. The current type "timestamptz"
does not store the time zone as a standard one should do. So I've made a
new type I've called timestampstdtz that does store the time zone as the
standard d
Hi
Was already implemented the timeout on the "SELECT
... FOR UPDATE" (non-blocking lock) and/or is possible known if the lock exist
on the specified ROW before executing the SELECT?
Please note: ours need is the timeout/verify at the
ROW level, not at the table level.
Is already OK? I
20 matches
Mail list logo
