The following bug has been logged online:
Bug reference: 2825
Logged by: Josh
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows XP
Description:Installation doesnt let me create username
Details:
When i try to install a postgres as a
The following bug has been logged online:
Bug reference: 3823
Logged by: Josh
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: windows server 2003
Description:Installing Permissions set still says there not
Details:
I tried installing
The following bug has been logged online:
Bug reference: 1670
Logged by: Josh
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.2, 8.0.3
Operating system: CentOS 4
Description:pg_dump fails on CentOS 4
Details:
pg_dump, as packaged in postgresql-8.0.3
_dump to /usr/bin as
root, pg_dump worked fine.
Thanks for the help!
--Josh
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message ca
Thank you both for clearing that up (and doing so quite quickly!).
The behavior makes complete sense now that I understand what is
happening here behind the scenes.
Regards,
Josh
On 3/3/2011 11:24 AM, Tom Lane wrote:
"Joshua McDougall" writes:
When using the pg_notify(text,text
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
Tom,
You can't have your cake and eat it too, Josh. If we make the RI
mechanism operate at a level underneath triggers, then we'll lose all
sorts of useful capability that people are depending on. A couple of
examples:
* the ability to log table changes caused by RI cascades
* t
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 (
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.
ut:
CREATE TYPE mytype2 AS (
j mytype
);
Really?
Ok, I'll have to work up a reproduceable case, because I'm definitely
getting the "public" qualification in the create type.
--Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
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
d to be up for that.
--Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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, 'jo
> 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
All,
What I did:
1. Set up 9.0a4 doing SR replication with a 2nd 9.0a4
2. Ran pgbench for a while.
3. Aborted pgbench with Ctl-C
4. Changed vacuum_defer_cleanup_age in postgresql.conf and reloaded
5. Ran pgbench again, and got:
Sidney-Stratton:pg90 josh$ pgbench -c 2 -T 300 bench
starting
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 subsc
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
Severity: major (data loss)
Versions Tested: 8.4.2, 9.0 HEAD
Test Case:
create table regex_test ( id serial not null primary key, myname text );
insert into regex_test ( myname )
values ( 'josh'),('joe'),('mary'),('stephen'), ('jose'),
('ke
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
rg> is broken. (In
the meantime, if you could just link to this e-mail address, or to a
page with this e-mail address, that would be a good temporary thing...)
Thanks,
Josh
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
http://www.cis.upenn.edu/~jbur
"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
The following bug has been logged online:
Bug reference: 2599
Logged by: Josh Tolley
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Fedora Core 5
Description:AM/PM doesn't work in to_timestamp in the middle of a
string
De
iption:IMPORT/EXPORT into PostgreSQL
> Details:
>
> How to carry out the import of information in POSTGRESQL?
>
This isn't a bug, and should probably be asked on -novice or -general
instead. That said, look at the COPY command.
http://www.postgresql.org/docs/current/static/sql-cop
> On Thursday 30 August 2007 21:15, Tom Lane wrote:
> > to_date and friends are fairly awful in terms of not throwing errors
> > when the input doesn't really match the format. I think what you
> > shoulda got here is a bad-input error. However, somebody's going to
> > have to do a major rewrite
On 8/31/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Josh Tolley escribió:
> > > On Thursday 30 August 2007 21:15, Tom Lane wrote:
> > > > to_date and friends are fairly awful in terms of not throwing errors
> > > > when the input doesn&#x
The bug message was cannot edit file permissions not set or something
along those lines.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ostgres |1 | t | t| t | |
> infinity |
> (2 rows)
> ***
>
>
> I tried
> delete from pg_shadow where passwd is null;
>
> but it's not working.
>
> Help me please
> oleg
pg_shadow is a view based on pg_auth
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.
This is probably more like an "undesired feature" than a software bug, but
it was behaviour that I did not expect.
thanks!
Your name : Josh Goldberg
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (exam
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
I found that PAM authentication in 7.2.3 doesn't appear to work
properly. It appeared to me that the server wasn't waiting for
the PAM conversation to complete before it rejected the request,
so I did a little rewrite on the auth.c file to sort of force
things to prompt for a password and then sho
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
-
I'd be tempted to
just delete the row from pg_tables, but the rows are there, and I want to clobber
them. Any ideas?
Thanks,
Josh Eno
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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
n our case
was that the "solaris" define is not defined by our compilers or by
postgresql itself.
The patch below simple has it check SHM_SHARE_MMU instead, which should
work fine. I verified (with 'pmap') that the database is now using ISM
on its shared memory, af
Bruce Momjian wrote:
Josh Wilmes wrote:
Nope, __solaris__ is not defined on our system either.
I thought our configure defined __portname__ for every platform, but I
don't see that anywhere, so it seems we rely on the compiler to supply
defines for the cpu and OS.
Does src/tools/ccsym sho
Nope, __solaris__ is not defined on our system either.
--Josh
Bruce Momjian wrote:
Yikes! We thought we were already using ISM on Solaris.
Would you test the attached patch? It uses _solaris_ rather than
SHM_SHARE_MMU in the define test. Does that work too
Seems like the BEST case would be to have a configure test verify that
it works and define something if it does, but i don't know what such a
test would look like.
--Josh
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
! #if defined(sun) &&
ename database
You will get some odd feedback on STDERR:
on Linux, file with only a block comment:
[EMAIL PROTECTED]:~/Documents/oss/postgres> psql -f tempit2.sql -U postgres test1
psql:tempit2.sql:1: [EMAIL PROTECTED]:~/Documents/oss/postgres>
on OSX:
josh% /usr/local/pgsql/bin/psql -U po
Guys,
> I can confirm the problem. It happens in more cases than Josh mentions,
> as well:
> -- running the file with \i also shows the problem
> -- there can be blank lines and whitespace after the
> block comment, and it still shows up.
This bug is still
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
1 - 100 of 253 matches
Mail list logo
