Larry Rosenman [EMAIL PROTECTED] writes:
Has the idea of putting the infrastructure in place to allow a full pathname
to be fed to DT_SONAME been totally killed?
What makes you think you need new infrastructure? The HPUX port has
used a full-path rpath for years.
Can you add LIKE parent table TO CREATE TYPE too ?
There could be also CREATE TYPE ble AS ( LIKE parent_table|other_type) );
and CREATE TABLE ble ( LIKE some_type ) , and each colmnu from compose
type will be add to table ble with static (NOT) NULL, and without
defaults.
what do you think ?
I have applied a patch to have NEED_REENTRANT_FUNC_NAMES _require_ the
*_r libraries, rather than the old behavior of just using the *_r
libraries if they exist. With my new research documented in thread.c, I
think this is the proper way to handle it.
I have also marked FreeBSD as not requiring
Sounds good to me too.
---
Joe Conway wrote:
Tom Lane wrote:
Today it occurred to me that we could look in pg_opclass for a default
btree opclass for the datatype. If we find one, then the Equal and Less
members of
The original patch added rpath only for libpq and a few other places.
Larry, I think you should submit a patch that follows what HPUX does. I
think you only need to modify the unixware portion of Makefile.shlib. I
think the original objection was having to put stuff in libpq/Makefile.
This time it's on RH8.
The distributed RPMs complain thus:
[EMAIL PROTECTED] andrew]# rpm --test -Uhv postgresql-*7.3.4-1PGDG.*.rpm
error: Failed dependencies:
perl(Pg) is needed by postgresql-contrib-7.3.4-1PGDG
[EMAIL PROTECTED] andrew]#
Strangely enough, I look for it and see this:
It looks like that right now if you have multiple constraints
with the same name on different tables and some are deferrable
and some are not, SET CONSTRAINTS name DEFERRED will fail when
it reaches the not deferrable constraint. Is this the behavior
we want, or do we want it to defer the
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (ivan) wrote:
Can you add LIKE parent table TO CREATE TYPE too ? There could be
also CREATE TYPE ble AS ( LIKE parent_table|other_type) ); and
CREATE TABLE ble ( LIKE some_type ) , and each colmnu from compose
type will be add to
Are these IPv6 deficiencies addressed?
---
Tom Lane wrote:
The IPv6 patch seems to still be a few bricks shy of a load. Grepping
for places that handle AF_INET but not AF_INET6 revealed these
unimplemented features:
Sean Chittenden wrote:
auth.c: In function `pg_krb5_recvauth':
auth.c:294: structure has no member named `user'
Ooops, my fault --- I didn't build with Kerberos support after
changing those field names.
Now that I think about it, there might be similar omissions in the
PAM or
I have added this email to CVS as src/tools/error_text. Any changes to
it?
---
Tom Lane wrote:
I'm about to start going through the backend's elog() calls to update
them to ereport() style, add error code numbers, polish
Bruce Momjian [EMAIL PROTECTED] writes:
I have added this email to CVS as src/tools/error_text. Any changes to
it?
Waste of CVS space; the real documentation is in SGML:
http://developer.postgresql.org/docs/postgres/error-style-guide.html
regards, tom lane
Oh, removed.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have added this email to CVS as src/tools/error_text. Any changes to
it?
Waste of CVS space; the real documentation is in SGML:
Has this been addressed?
---
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Presumably, the is_superuser parameter was intended to make the updating
of psql's prompt more accurate when SET SESSION
I've noticed that when the stats are wrong (like
in cases where you've loaded data but reltuples
hasn't been updated yet) that a hashed NOT IN
seems to take a significant time penalty. Is
this to be expected?
On a pktest table with 1 million integers and a dual table with a single
integer and
On Sat, 16 Aug 2003, Stephan Szabo wrote:
I've noticed that when the stats are wrong (like
in cases where you've loaded data but reltuples
hasn't been updated yet) that a hashed NOT IN
seems to take a significant time penalty. Is
this to be expected?
On a pktest table with 1 million
Added to TODO:
* Add TRUNCATE ... CASCADE
---
Josh Berkus wrote:
Guys,
I wouldn't care for that either. The prior suggestion of TRUNCATE tab
CASCADE (to truncate any tables with FK dependencies on the
Is this a bug?
---
Robert Treat wrote:
On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This this a TODO? Keep in mind if we follow the syntax of VACUUM and
(7.4) CLUSTER, that
Added to TODO:
* Add ALTER DOMAIN, AGGREGATE, CONVERSION, SEQUENCE ... OWNER TO
---
Andreas Pflug wrote:
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
But should the CREATE DOMAIN
I assume this has been addressed?
---
Neil Conway wrote:
I'm working on writing a script that automatically tests all the
built-in functions. As a first step, I just passed NULL for all
of the arguments for each built-in
Added to TODO:
o Allow pooled connections to query prepared queries
o Allow pooled connections to close all open WITH HOLD cursors
---
Neil Conway wrote:
On Fri, Aug 08, 2003 at 04:00:22PM -0400, Tom Lane
Stephan Szabo [EMAIL PROTECTED] writes:
with reltuples=1000 for pktest, query takes about 96 seconds
reltuples=1, query takes about 15 seconds
reltuples=10, query takes about 8 seconds
Errm, I meant in the cases where it still chose a hashed
subplan. Stupid cold medicine.
I'm
On Sun, 17 Aug 2003, Bruce Momjian wrote:
Is this a bug?
I don't think so. I'd say this is the expected behavior. Part of the
point is that it fails without checking for matching rows.
Robert Treat wrote:
On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED]
Stephan Szabo [EMAIL PROTECTED] writes:
On Sun, 17 Aug 2003, Bruce Momjian wrote:
Is this a bug?
I don't think so. I'd say this is the expected behavior. Part of the
point is that it fails without checking for matching rows.
To do anything else, you'd have to solve some locking and/or
I stumbled across this behavior today and it seems strange if not a bug:
-- this seems wrong
vsconf=# create table foo (f1 char(1));
CREATE TABLE
vsconf=# insert into foo values(' ');
INSERT 9002011 1
vsconf=# select ascii(f1) from foo;
ascii
---
0
(1 row)
-- this is what I'd expect
Is there a TODO here? Text?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What do you actually get back from a Parse request?
Nothing. If successful, it creates a prepared statement inside
Stephan Szabo [EMAIL PROTECTED] writes:
Basically, the first thing I noticed was that changing reltuples
on the pg_class row for a table affected the speed of
explain analyze select * from othertable where foo not in (select bar from
table);
even when the plan wasn't changing, seqscan +
Added to TODO:
* Allow PREPARE of cursors
---
Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
I'm beginning to think that was a serious omission. I'm tempted to
fix it, even though we're past
Added to HISTORY:
New pg_get_triggerdef(prettyprint) and pg_constraint_is_visible() functions
---
Christopher Kings-Lynne wrote:
I think the new pg_get_triggerdef and pg_constraint_is_visible functions
aren't
On Sun, 17 Aug 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
with reltuples=1000 for pktest, query takes about 96 seconds
reltuples=1, query takes about 15 seconds
reltuples=10, query takes about 8 seconds
Errm, I meant in the cases where it still chose a hashed
30 matches
Mail list logo
