Version: 8.3.5
Install: self-compile on 64-bit Ubuntu Linux
also reproduced by AndrewSN on another platform
Summary: self-referential FKs are not enforced properly in the
presence of BEFORE triggers
Test Case:
-- create two tables, one of which is the master table (reftable) the
Tom Lane wrote:
Josh Berkus writes:
Summary: self-referential FKs are not enforced properly in the
presence of BEFORE triggers
This isn't a bug. If you create triggers that prevent the RI actions
from being taken, it's your own problem.
Huh? Since when was it OK by
f the example, you'd see that I'm saying that
the trigger should *fail*, with an error. Not work.
Throughout the history of the project, no functionality which ends in a
inconsistent data state has ever been acceptable which I can recall.
When did we change our policy?
--Josh Berkus
--
schema_path. This is inconsistent with all other database objects,
which use "SET search_path" to qualify the correct schemas.
This is only a real problem in that it may interfere with backup and/or
schema comparison automation (like I'm trying to write right now).
--Josh B
Jeff,
Functions are similar, actually. The argument list needs to specify
schema paths as well, if it's not in some expected place (I think it
does so for all schemas other than pg_catalog).
Except that they don't appear to do so.
--Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgr
r most other objects "public" is also excluded as well as
pg_catalog. For CREATE TYPE, "public" is explicit.
Have you considered working from the "custom" format rather than text?
I'm not sure whether it solves your problem, but I think it provides the
mos
Tom Lane wrote:
Josh Berkus writes:
When doing pg_dump in text mode, complext types will be dumped like this:
CREATE TYPE complex_foo (
var INT,
gar TEXT,
natch public.foo_type
);
You didn't say which schema "complex_foo" is in?
Public.
Jeff Davis wrote:
On Fri, 2009-02-27 at 01:24 -0500, Tom Lane wrote:
Are you entirely sure that they don't?
Oh, you're right, of course:
postgres=# create type public.mytype as (i int);
CREATE TYPE
postgres=# create type public.mytype2 as (j mytype);
CREATE TYPE
-- pg_dump output:
CREATE TYP
matter.
Um, there's no such thing as PostgreSQL 8.7.3. The latest stable
version is *8.3.7*. Was that the version you meant?
If that's the case, then everything you want is here:
http://www.postgresql.org/download/linux
http://www.postgresql.org/ftp/source/v8.3.7/
--Josh Berkus
> It's too bad you didn't capture a stack backtrace at step #3 or step
> #6. If you manage to reproduce the problem, that would be a good
> thing to try to get.
It never actually crashed. And, of course, this was happening right
when I needed to go home and the server needed to be up for that.
ng first, and then
afterwards thought it might be worth reporting.
Anything I can mine out of the logs or files?
--Josh Berkus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Pavel, all:
Apparently if you use one returns table function to call a 2nd returns
table function, it returns a recordset which consists entirely of nulls.
Here's the test case:
create table srf_data ( id serial, cat int, val text );
insert into srf_data ( cat, val ) values
( 1, 'josh' ),
( 1, '
> val1 is just as ambiguous. I think you got bit by the name collision;
> the output parameters would start out NULLs and thus lead to the
> described behavior, in versions before 9.0.
Aha, yeah, that's probably it. Take this example as the reason we had
to change the behavi
All,
I tested Noel's test case and verified that it does, in fact, break.
And functions on 8.4.
--Josh Berkus
Original Message
Subject: [TESTERS] Numerics of diffrent scales Raises Type Mismatch
Error in a Set Returning Function
Date: Tue, 2 Mar 2010 20:07:07 -0800
From:
Should have thought of that.
--Josh Berkus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
NING: PD_ALL_VISIBLE flag was incorrectly set in relation
"pgbench_tellers" page 1
... not one I'm familiar with. Issues?
--Josh Berkus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ions. So I think we should work on
making it less kludgy.
Ultimately we're going to need publish-XID-to-master, but that's not
realistic for 9.0.
--Josh Berkus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
> That's better, I was worried you'd gone all complimentary on me.
Never fear that!
Was that setting originally part of your design for HS? If so, why did
you back off from it?
--Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http:
iven what I've been
looking at, it seems like a LOT of work.
--Josh Berkus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
d: the 2nd replace should have succeeded. Or it
should have given a user-friendly error message. Opinions?
--Josh Berkus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
of rows which are
returned by the query. We should get 7 rows, 3 of which have an empty
array or a NULL in the 2nd column.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.co
On 4/5/10 9:16 PM, Josh Berkus wrote:
> I can't see how this is anything but a bug; as far as I know, nothing in
> the target list is allowed to restrict the number of rows which are
> returned by the query. We should get 7 rows, 3 of which have an empty
> array or a NULL
to allow an SRF in the
target list to restrict the number of rows output. A subselect in the
target list does not do so. However, that's completely another discussion.
--Josh Berkus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http:/
ions, including all builtins, not just user-defined
functions.
Both views and functions operate normally when called via sql, however.
Please note that I may, due to my parallel install, be accidentally
using ver. 7.0.3 psql with the 7.1b3 Postgres. If so, I;d like to know.
-Josh Berkus
--
_
to give us their proprietary code
so that we can make compatible drivers. :-(
-Josh Berkus
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (4
"x\\y","x y"}
(1 row)
scratch=# select tarr[1] from test_arr;
tarr
--
xy
(1 row)
scratch=# select tarr[2] from test_arr;
tarr
--
x\y
(1 row)
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP
think we should be using the ARRAY[] format for display
anyway, but that would break some backwards compatibility ...
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ign
parse an array value unambiguously.
Ok, so "yes, it's inconsistent, but we don't want to break backwards
compatibility." I can buy that ...
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
2001-07-10 11:00:00-07
It appears that Spring Daylight Savings Time causes PostgreSQL to change my
time zone. Only the spring, mind you, and not the fall. This is
potentially catastrophic for the application I'm developing; what can I do to
see that it's fixe
ther, it seems that the whole "Interval" section of Postgres,
possibly one of our greatest strengths as a database, has languished in
the realm of inconsistent behavior due to lack of interest. Is there
anything I can do without learning C?
-Josh Berkus
---(e
avoid dealing
> with
> the implementation complexities and usage patterns which are
> uncovered
> when trying to do more.
Ok, so how should things work, then? While I agree that SQL92's spec
is awkward and limited, we'd need a pretty good argument for breaking
standards.
m, as obviously this
could be a critical issue for production databases. However, I'm not sure
how to submit the files as they are very large (> 90mb) and how can I send
the original database not as a backup file?
--
-Josh Berkus
Aglio Database Solutions
ave the Postgresql log files for the last few days, but my mastery of
command-line text parsing is not sufficient to find the relevant section of
the log.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP
original DB. If
> this works, we know it's data related. Ugh.
It's not data related ... the missing object is a view.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 2: you can get off all list
testing to see if I can reproduce this issue on 7.3b1. I'll
e-mail you with a test database if I can.
-Josh Berkus
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAI
of this_row is by re-querying
the source table. While a relatively easy workaround, this behaviour is
annoying and inconsistent. It would be nice to fix in 7.3.1 or 7.4.
Thanks for your attention.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
--
Neil,
> Unless anyone sees a problem with this, I'll work on this. I
> definately think it's inappropriate for 7.3.1 though.
Thank you!
-Josh Berkus
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://ww
Ruslan,
I'm afraid that you sent your message to the PostgreSQL Bugs Mailing
List, where we cannot help you with Cisco problems. Please try an
appropriate Cisco mailing list.
-Josh Berkus
---(end of broadcast)---
TIP 5: Have you checke
e from backup (you do have a
backup, yes?)
9) start using postgresql again.
Good luck!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
g.c ... does everyone think it would be a good idea to post a notice on
the lists of the issue and the fix?
While it easy enough to tell users, "Upgrade, or get a UPS" this is not
practical for everyone.
And is there any potential issue with swapping those two lines?
ore the CAST(MONEY AS NUMERIC) function so that
users can migrate old databases to the new data type. In later versions of
postgres, I suggest that MONEY be abandoned as a true data type and instead
become a DOMAIN of NUMERIC for those converting.
--
-Josh Berkus
Aglio Database S
Bruce,
> They are probably better off just changing the column data type, _and_
> we need someone to get MONEY working as an extented NUMERIC type.
Apparently D'Arcy McCain is going to do this. Go, D'arcy!
--
-Josh Berkus
Aglio Database Solution
NERAL as well), which would
spare you the pain of translating your questions.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ship people so that we can resolve this?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
one function.
>
> What do you mean by "refuses"?
The function is silently dropped from the pg_dump file. This happens in both
binary and sql-script modes, and I've tracked the log to see if pg_dump is
reporting an error to postmaster. No luck.
But I'll try late
ts, meaning it would silently miss
> objects that were missing expected collateral objects.
Return type is TEXT, so I think that's OK too. However, this database does
have some pretty complex dependancies.
I just tested. This is still a bug in 7.3.0. I will download and test 7.3.2
Folks,
This bug in 7.2.3 and 7.3.0 seems to have been fixed as a side effect of some
of the other fixes in 7.2.4 and 7.3.2. We're not sure exactly *how*, but the
bug occurs on 7.2.3 and not on 7.2.4.
Did anybody do anything to patch dependancy tracking 7.2.3 ==> 7.2.4?
--
-Jos
That we add a warning in the 7.3 release notes about the breaking of
backward compatibility.
Thoughts?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
t found.
It seems that subselects aliased in the SELECT clause of a GROUP BY query
cannot be referenced in the HAVING or ORDER BY clauses of any query.
I'd guess that this is being worked on for 7.4/8.0?
Thanks!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
hat you mean. Given that I (along with at least a dozen posters
to the SQL list) was confused that our HAVING/ORDER BY will accept column
aliases but not sub-select aliases, would this be worthy of a FAQ item?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
covered because this is a production system
and I had to get it up and running from backup by 9am.
Does this sound like a crash during VACUUM, or just like it needed more time?
If anyone wants to analyze, I have a complete backup of the post-problem
PGDATA directory. The host system is RH Linux 8.
n't really an option, because the indexes support some
of the data transform steps.
I'm wondering if I need to REINDEX more often; I think I'll try that next.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
been in favor of reducing problematic implicit conversions. But
VARCHAR --> TEXT is one that needs to stay, as there's no possibility of
ambiguity, and most users count on doing it transparently.
Either that, or we need to build all string function for varchar.
--
Josh Berkus
Aglio Da
did in 7.2.4 and I think it did in 7.3.4.
Are we now defaulting COUNT(*) to BIGINT? IF so, that's going to be a *huge*
backwards compatibility warning for people
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
licit conversion from BIGINT to INT for function calls?
However, it's certainly possible it happend in 7.3, as this particular app was
not ported to 7.3.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: Have
Tom,
> That could be --- I don't recall exactly when we decided implicit
> bigint->int conversion was a bad idea ...
Well, it is a bad idea, so I won't argue. Sorry for the false alarm.
--
Josh Berkus
Aglio Database Solutions
San Francisco
-
vhost
where idvhost = 100);
DELETE 1
test1=>
According to Neil, what's happening is that "select iddomain" in the subquery
is grabbing the iddomain column from the forwarding table in the outer query.
This is not intutive, for certain; however, what I don't know is if
eted your
> whole table, which is what I think will happen here...
Yup, that's what happened.
Wasn't sure.We're OK then.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 8: explain analyze is your friend
on writer (Bricolage) looking
for failure messages on STDERR.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
present in RC2. Are we going to fix it before release?
According to David W., it really screws up the error-detection code on
Bricolage, and I'd think that other applications might have the same problem.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
as that user.
Core dump file is available.Strace can also be done if desired.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Neil,
> Can you post a stacktrace? (Building the postmaster with debugging
> symbols first would be nice.)
I'll see what I can do. A regular strace should be easy.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end o
Tom,
> Is this the bsearch-of-no-elements problem recently discussed?
> (If you have other users who do have passwords, then it's not...)
Actually, it could be. Is it patched in the current source code?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---
known
issue with WAL recovery on indexes in 7.2.4. Neil thought there was.
--
-Josh Berkus
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solution
months of testing before release.
--
-Josh Berkus
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (415) 565-7293
for law firms, small bu
WAL replay would
> faithfully update the pg_class row, but the index file would still be
> empty :-(
Would this be back-patchable by a good PG hacker? The client has $$$.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)--
le_mergejoin=true;
SET
jwnet_test=# set enable_nestloop=false;
SET
jwnet_test=# select * from sv_cases;
ERROR: variable not found in subplan target lists
If there is a patch for this that isn't in 7.4.1, please let me know where I
can grab it other than the archives, as the HTML formatting is
status s1 (cost=0.00..1.91
rows=4 width=16)
Filter: ((relation)::text =
'text_lists'::text)
-> Sort (cost=1.79..1.85 rows=24 width=49)
Sort Key: text_lists.status
ee if it's
> fixed.
Hmmm ... problem is, per my last e-mail, the bug is not reproducable off of
this particular database instance -- if I copy it to my laptop, the bug goes
away. And even though it's not a production database, it *is* a production
*server*. Which means that I can
ace the bad view in the next hour or so.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
want to analyze it further.
> The cost numbers here are very small; are the tables themselves small, or
> did you reload them too?
The tables are quite small, the largest < 200 rows. This view just links a
bunch of reference lists.
--
-Josh Berkus
Aglio Database Solutions
San Francis
ing::text
JOIN status s2 ON list_values.status = s2.status AND s2.relation::text =
'list_values'::character varying::text;
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
o_text" near line 12
Removal of the Raise Notice statement will cause the procedure to execute.
No biggie, just wanted to get it on the bug list.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
,
and the only 7.3.3 --> 7.3.6 core dumping issues I see relate to pg_dump, or
Solaris 7.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if
dig for more information ... and get them to upgrade to 7.3.6.
--
-Josh Berkus
__AGLIO DATABASE SOLUTIONS___
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (415) 565-729
rought to affect
only Solaris 7 or 8. However, it turns out that they are using a
pre-release of Solaris 9, so they have the same issue. They've been told to
upgrage to 7.3.6.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)-
Folks,
Is there any known issues with index file corruption in the event of a
power-out during REINDEX with 7.2.4?
I *think* the problem is this client's peculiar hardware, but wanted to
eliminate any potential known issues.
--
-Josh Berkus
__AGLIO DAT
ehavior, in CHAR for
7.5:
[11:03:25] darcy=# SELECT length('1'::char(4));
[11:03:25] length
[11:03:25]
[11:03:25]1
[11:03:25] (1 row)
[11:03:29] is 7.5
pg743=> select length('1'::char(4));
length
4
(1 row)
(on 7.4.3)
Are these changes
x27;::char(4) || '"'::char(4);
?column?
--
""
(1 row)
Depending on the spec, it seems to me that the above should result either in a
char(4) of " " or a char(12) of " " . But we get a text value.
Is this the SQL spec? Is there another r
" for reading: No such file or
directory
child process exited with exit code 1
Is this intentional? The first dozen or so commands work fine with a relative
path, and this executes fine with an absolute path for both -D and -L.
SuSE 9.1, GCC 3.3.3
--
Josh Berkus
Aglio Database Sol
Tom,
> It might be worth absolut-izing this path in initdb before it's
> passed down, but I can't get exceedingly excited about it.
Well, once again let me check the docs to make sure people are warned about
this
--
Josh Berkus
Aglio Database Solutio
rt, because INITDB for Sunday's CVS
would not run without the -L option.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
/pg80b
I did not move the tree.
I will drop the data directory and re-run it so I can cut and paste the error
this afternoon.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
e invocation option -L.
[EMAIL PROTECTED]:/usr/local/pg80b/bin>
I don't recall having this issue with 7.4.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please se
the server.
Frankly, the circumstances are peculiar enough that I don't expect you to do
anything about this bug report; instead I'm filing it in case any related
problems crop up with 7.4's PSQL.
And, yes, I tried re-connecting in case this was somehow line noise.
--
__Aglio Da
seems like, in
PSQL, the use of non-ASCII characters should require quoted identifiers, but
apparently not?
--
__Aglio Database Solutions___
Josh BerkusConsultant
[EMAIL PROTECTED]www.agliodbs.com
Ph: 415-752-2500Fax: 415-752-2387
2166 Haye
# \d cases
ERROR: column "reltablespace" does not exist
jwnet_test=#
I thought that we were going to be better about backward compatibility in this
version?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
only reference to the error I can find
is for CLUSTER, which is confusing because none of the tables involved are
clustered.
Is this related to the index problem fixed in 7.4.x?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)-
er it. Any workaround to fix?
> I'm quite sure you couldn't get this error from anything except CLUSTER
> or TRUNCATE in 7.4 though. Seems like your client-side code is in error
> to be fingering a plain SELECT as the cause.
Yeah, well, I can't get the client to install
problem with
the data transfer.Maybe re-create the table?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Tom,
> Yeah, I think you're stuck with doing that.
BTW, this is a pretty nasty error, although apparently infrequent give the
lack of list e-mails. Can we fix it for 7.4 series?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of b
Guys,
Pardon me if this is redundant, but I've just noticed that the MONEY type
still exists in 8.0b2.Didn't we say that we were getting rid of it?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TI
s get rid of it and replace it with a DOMAIN of NUMERIC.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
.07m^3
But you can't reasonably:
10USD == 6.25UKL
... because that would require a query to money.yahoo.com to establish.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you sea
ny easy way to query "give me the
first row which is not locked"?If I tie pg_locks to a query, will I get
wierd effects? Just musing
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 1: s
nd-lock were a single statement, how would a
race condition result? How could I test for it?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
gcc (GCC) 3.3.3 (SuSE
Linux)
(1 row)
webmergers=# select 3000::NUMERIC*1024*1024;
?column?
3145728000
(1 row)
webmergers=# select 3000*1024*1024;
?column?
-
-1149239296
(1 row)
--
__Aglio Database Solutions_______
Josh BerkusConsultant
[
TIMESTAMP);
age
9 mons 27 days 11:17:19.889547
(1 row)
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
robably don't need to change
it.
--Josh
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
I missing a package?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
1 - 100 of 196 matches
Mail list logo
