ing Bruce, but I fear this
is one itch that'll go unscratched.
Rest assured I'm not about to storm off and replace all my installations
with MySQL :-)
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ms to
have noticed before now.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"
password retrieved from file "/home/richardh/.pgpass"
I'm a bit puzzled how it manages without the escaping in the first case.
There's a lack of consistency though that either needs documenting or
fixing.
[1] http://www.postgresql.org/docs/9.1/static/libpq-
=# select '1894-01-01'::timestamp with time zone;
timestamptz
--
1894-01-01 00:00:00-05:17:32
Floating-point timestamps? Although I thought integer was the default
for 9.x - hmm INSTALL says since 8.4
--
Richard Huxton
Archonet Ltd
--
Sent via pgs
7;
COPY (SELECT :x) TO STDOUT;
-- Doesn't work
\copy (SELECT :x) TO '/tmp/test2.txt'
=== end script ===
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
configuration-for-extension. It allows the extension to decide whether
to load the new config or reject it. It lets you test/demonstrate
multiple configurations fairly simply.
The "system_data" column scenario can then be a default implementation
of read_your_config().
--
Richard Huxton
Ar
od for indexing hypothetical data ;-)
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
g system rather than a new app I'm pretty sure it would have
confused me for a lot longer than it did.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
olumns that get placed after the numeric. If you went from 10 bytes
down to 8, that should be visible.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tgres from the existing psql
Arse.
It's little details like this that demonstrate why I'm a user and not a
hacker :-)
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
Trying to format the data in the backend is probably just going to
frustrate writers of different clients (of which I think we have quite a
few now).
* These functions could then be back-ported as an admin-pack too for
clients/apps that wanted cross-version compatibility for these sorts of
th
e alpha testing
cycles on it."
Should we do this? Patch attached.
Any reason not to add a line to the 9.0 docs/release notes saying
"WARNING: The PGDG currently plan to change this setting's default in 9.1"?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers m
On 30/06/10 18:11, Magnus Hagander wrote:
On Wed, Jun 30, 2010 at 18:33, Richard Huxton wrote:
IMHO The real solution would be something that could strip/rewrite the
constraint on restore rather than trying to prevent people being stupid
though. People *will* just tag their functions as
p can no longer
restore the oldest record :-(
IMHO The real solution would be something that could strip/rewrite the
constraint on restore rather than trying to prevent people being stupid
though. People *will* just tag their functions as immutable to get them
to work.
--
Richard Huxton
queued WAL
before letting new transactions start. Or perhaps it replays any vacuum
activity it comes across and then stops. That should sync with #2
assuming the slave doesn't lag the master too much.
5. I've been mixing "defer" and "delay", as do the docs. We should
On 26/02/10 14:45, Heikki Linnakangas wrote:
Richard Huxton wrote:
On 26/02/10 08:33, Greg Smith wrote:
I'm not sure what you might be expecting from the above combination, but
what actually happens is that many of the SELECT statements on the table
*that isn't even being updated* ar
x27;s hard to do, but that would really be
the most robust fix possible.
Something like snapshotting a filesystem, so updates continue while
you're still looking at a static version.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
ably meaning we need *another* config setting to prevent excessive
bloat on a heavily updated table on the master.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 25/02/10 17:10, Andrew Dunstan wrote:
Richard Huxton wrote:
Presumably "Safe" just clamps down and my
sub isn't marked as acceptable. Is this intended, or am I doing
something stupid?
It's intended (at least by me).
Also, please see the recent discussion about load
unction "add_one_e"
-- plperlu - TestModule::add_one
richardh=# SELECT add_one_u(1);
add_one_u
---
2
(1 row)
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
CT;
CREATE FUNCTION add_one(integer) RETURNS integer
AS 'My::Package', 'add_one'
LANGUAGE plperl STRICT;
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nstall the adminpack etc. over the top of your now working installation.
If you didn't find the data directory, create it, grant permissions to
"postgres" and then try a full re-install.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
- not sure
those carry any extra info. It also treads on the toes of
"PG->not_a_function" should such a beast be needed.
I like "F->funcname" or "FN->funcname" myself.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On 16/02/10 17:51, David E. Wheeler wrote:
On Feb 16, 2010, at 9:43 AM, Richard Huxton wrote:
Perhaps it would be better to be explicit about what's going on?
SEARCHPATH->function()
SCHEMA('public')->function2()
Or did "SP" mean "Stored Procedure"
t about what's going on?
SEARCHPATH->function()
SCHEMA('public')->function2()
Or did "SP" mean "Stored Procedure"?
On a (kind of) related note, it might be worthwhile to mention
search_path in the docs and point out it has the same pros/cons as unix
file pa
On 15/02/10 10:32, Tim Bunce wrote:
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
Is there any value in having a two-stage interface?
$seq_fn = get_call('nextval(regclass)');
$foo1 = $seq_fn->($seq1);
$foo2 = $seq_fn->($seq2);
;
$foo1 = $seq_fn->($seq1);
$foo2 = $seq_fn->($seq2);
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
struck me:
1. Why have a separate recovery.conf file rather than just put the
commands inline? We can use the include directive to have them in a
separate file if required.
2. Why have a finish.replication file, rather than "SELECT
pg_finish_replication()"?
--
Richard Huxton
Archon
On 09/02/10 14:25, Jeroen Vermeulen wrote:
Richard Huxton wrote:
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice.
Do you mean:
1. Rollback the current query and start again
2. Mark the plan as a bad one and plan again next
turns out
better than the specific plan (due to bad stats or config settings or
just planner limitations). The question is (I guess): How many more
winners will there be than losers?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
be
Wait for it
9.0.
You don't have a code-name. All the cool kids have code-names for their
projects.
There - that should distract everyone from actual release-related work
for the next week or so :-)
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (
Greg Stark wrote:
> On Tue, Dec 1, 2009 at 9:57 PM, Richard Huxton wrote:
>> Why are we writing out the hint bits to disk anyway? Is it really so
>> slow to calculate them on read + cache them that it's worth all this
>> trouble? Are they not also to blame for the &
writing out the hint bits to disk anyway? Is it really so
slow to calculate them on read + cache them that it's worth all this
trouble? Are they not also to blame for the "write my import data twice"
feature?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing
',NULL]);
It should, but probably depends on whether "IS NOT DISTINCT" should be
considered an "operator".
http://www.postgresql.org/docs/8.4/static/functions-comparisons.html#AEN16561
Got caught by the same thing a couple of days ago.
--
Richard Huxton
Archonet Ltd
--
mporal Keys - We need two types of temporal keys. A primary key,
>> exclusion type prevents overlap so someone isn't at two places at the
>> same time.
You're going to upset a lot of managers if they can't do that ;-)
--
Richard Huxton
Archonet Ltd
--
Sent via
low string operations. Would string comparisons be safe (because a
literal would be caught before the view gets evaluated)?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> a │ b
> ───┼───
> (0 rows)
>
> still I have not bad result, but, yes, I see what I could not to see.
Ah - that's the problem. It's not possible to get the "hidden" values
into the result set, but it is possible to see them. It only matters if
you are using the view to p
Richard Huxton wrote:
> Heikki Linnakangas wrote:
>> CREATE VIEW phone_number AS
>> SELECT person, phone FROM phone_data WHERE phone NOT LIKE '6%';
>
>> CREATE OR REPLACE FUNCTION expose_person (person text, phone text)
>> RETURNS bool AS $$
>
ostgres=# create view v as select * from x where b <> 20;
^^^
This is the expression that needs to be expensive. Then the exposing
function needs to be cheap. That makes the planner run the exposing
function first.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers maili
'6%';
END;
$$ LANGUAGE plpgsql COST 999;
CREATE VIEW phone_number AS
SELECT person, phone FROM phone_data WHERE NOT row_hidden(phone);
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
e the behavior user-controllable, something along the lines of
> "CREATE RESTRICTED VIEW ...", to avoid the performance impact when views
> are not used for access control.
Not pretty, but solves the problem.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David E. Wheeler wrote:
> On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
>
>>> Why wouldn't the entire TOC be in a collapsed list?
>>
>> Permanently on-screen? My only concern there would be for people viewing
>> on phones etc.
>
> I have to admit
David E. Wheeler wrote:
> On Sep 29, 2009, at 8:55 AM, Richard Huxton wrote:
>
>> For the browser, does the following match what you're after, Andrew?
>> - clicking chapter title opens the browser panel
>> - panel stays open until you click close icon
>> -
Peter Eisentraut wrote:
> On Fri, 2009-07-17 at 13:58 +0100, Richard Huxton wrote:
>> 2. Titles on navigation links.
>> Run ./STYLING/title_links.pl and it should add title attributes to the
>> navigation links. This means hovering over the top links gives the title
>&g
sumably want to meet:
- no external js libraries (or do we care, if we just reference it from
google?)
- navigation is optional, disabling js leaves docs as at present
- works on all reasonable browsers (anything not IE6)
- works online and in downloaded docs (except Windows .chm of course)
--
sql text
, echo boolean
) RETURNS text LANGUAGE plpgsql AS $exec$
Perhaps another two functions too:
list_all(objtype, schema_pattern, name_pattern)
exec_for(objtype, schema_pattern, name_pattern, sql_with_markers)
Obviously the third is a simple wrapper around the first two.
--
Rich
er. After all, the first three characters are perfectly well
established.
I hope that provides some clarity.
It's useful to learn that `ROW(NULL, NULL)` is NULL, but I find the
whole thing totally bizarre. Is it me?
Yes, just you. None of the rest of us have any problems with this at all :-
n *at all*
- You can separate extension installation from usage (good for
multi-user setups).
Cons:
- Extra layer of indirection (find my namespace => namespace lookup =>
object)
- Extensions need to list what they export in what sections
- More code required
--
Richard Huxton
A
er's navigation (see upthread) that he uses
for the Bricolage docs does, however.
Ah, if you can change the overall layout then the world is your
shellfish of choice. Would it be possible to include jquery? It's
GPL/MIT dual-licence.
--
Richard Huxton
Archonet Ltd
--
Sent via p
uld
now be a link that toggles the menu on/off.
The menu could be as simple/complex as you like - this is just what I
hacked together by parsing the TOC on index.html
I've tested it on Firefox, Opera, IE7 and Safari. Realistically, the
only real problem platforms will be IE6 and perhaps
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan wrote:
Richard Huxton wrote:
Andrew Dunstan wrote:
Yes, really. What you suggest here is just not adequate, IMNSHO. I
don't want to have to scroll to the top or bottom of the page to get
navigation, and I want to be able to see the navigation and go where
I want dir
s, or something else here?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
first-served
- if your patch goes over the limit it goes in the next commit-fest.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
probably installed by default,
but they need not be hardcoded into the backend.
Presumably would help the prospective upgrader too. Upgrade tool can't
cope with the change to inet types? No problem, I *know* they're not in
use, since they're not loaded.
--
Richard Huxton
Archon
t of view, but
the idea is to map extension name to a schema. If possible, this should
work anywhere in PG that a schema can be specified.
So - If extension foo is installed in schema1 then ext:foo.fn1() is the
same as schema1.fn1()
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-
ssed rows? Also - compile settings, character set and
locale details might be relevant too.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f the problem is that whenever someone has
Windows-related difficulties there's no standard tools we can use to
diagnose.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ough.
> FATAL: could not reattach to shared memory (key=1804, addr=0170): 487
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
NOTICE 'r.b=%, r.c=%', r.b, r.c;
-- This works, though notice we treat the function as a row-source
SELECT (f1(a,b)).* INTO b,c;
RAISE NOTICE 'a=%, b=%, c=%', a,b,c;
RETURN true;
END;
$$ LANGUAGE plpgsql;
SELECT f2();
ROLLBACK;
--
Richard Huxton
Archo
es to the row
then deletions can be used to spot it.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Aidan Van Dyk wrote:
> * Richard Huxton [090109 12:22]:
>
>>> Yeah: the archiver process doesn't have that information available.
>
>> Am I being really dim here - why isn't the first record in the WAL file
>> a fixed-length record containing e.g. txid_
tart, txid_end,
time_end, length? Write it once when you start using the file and once
when it's finished.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ble and I haven't missed something - I'm still
> learning!
Have you considered restoring to a completely different database
(report1/report2) and just switching between them?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
t thinks this should be a service on the website too
(or even first)? Fill in web form, click button, get sample
postgresql.conf (with comments) back.
Add a tick-box asking if we can keep a copy of their answers and you
might get some useful usage info too.
--
Richard Huxton
Archonet Ltd
--
Sent
st executing the planner-node at this
point? You could scale with the cost of actually doing the tests.
> 3. Put in a narrow hack that will get us out of this specific case,
> but might still allow very slow proof attempts in other large cases.
>
> The specific narrow hack I'm cons
an and restart then we could just try the
quick-but-risky plan and if we reach 50 rows rather than the expected 10
try a different approach. That way we'd not need to gather stats, just
react to the situation in individual queries.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he
impact of all the options where the accessed tables weren't being
updated (where update = vacuum + HOT if I've got this straight).
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
7;s only one value here: "hot standby wal delay time before
cancelling query". Might be a shorter name.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
orry whether applications might be affected by an incompatible change.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs wrote:
On Thu, 2008-08-07 at 14:18 +0100, Richard Huxton wrote:
An attempt to write to user_emails by T0 will fail with an error.
All above correct
The point of doing this is that *if* T0 becomes the oldest transaction
it will *not* interfere with removal of rows on "user_e
both groups and can only be vacuumed based on
T0..Tn (presumably T0 is the oldest, since that's the point of the
exercise).
An attempt to write to user_emails by T0 will fail with an error.
An attempt to read from user_emails by T0 will be allowed?
What happens if I'm in ISOLATION L
one go to see an example of a problem.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
read up on
TOAST) so not readable as plain-text.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Treat wrote:
On Tuesday 01 July 2008 03:45:44 Richard Huxton wrote:
The only time we need to restore per-database settings is if the
database has been dropped. If you're not having the dump/restore
re-create the database then presumably you've taken charge of the
per-databas
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
So put forward a worked-out proposal for some other behavior.
IMHO the time a dump/restore should be issuing ALTER...SET on a database
is when it has issued the corresponding CREATE DATABASE.
So pg_dump
ing, just manually create the database with
whatever options you want and don't use --create.
I'm also wondering why it'd be bright to treat ALTER ... SET properties
different from, say, database owner and encoding properties.
Not sure what you mean here.
--
Richard Huxton
Richard Huxton wrote:
Richard Huxton wrote:
At present it means you can't reliably do:
DROP DATABASE foo;
pg_restore --create foo.dump
I'd then have to either hand edit the dumpall dump or wade through a
bunch of errors checking that none of them were relevant.
Actually, I&
Richard Huxton wrote:
At present it means you can't reliably do:
DROP DATABASE foo;
pg_restore --create foo.dump
I'd then have to either hand edit the dumpall dump or wade through a
bunch of errors checking that none of them were relevant.
Actually, I'm not sure pg_dumpall d
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Is it desirable that pg_dump doesn't dump config settings set via ALTER
DATABASE?
Well, it's intentional anyway: that's handled by pg_dumpall. The basic
design is that anything that can be seen from "outsi
steel trap of a mind letting something like this slip through. Obvious
problem settings would be: datestyle, locale, default-text-search
Is this a deliberate behaviour of pg_dump or just an unscratched itch?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-ha
ables then the foreign-keys can be skipped.
If the restore checksum doesn't match the dump then it can issue a
warning, but continue and run the full fkey check.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
to commit now.
So ... back to your regularly scheduled development.
Is there a tag in the CVS to mark this point, or better still a tarball
that people like me can check out and play with over the next month or two?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing l
My 8.3.1 installation psql \h only gives me:
Syntax:
ALTER VIEW name RENAME TO newname
Ah, you use ALTER TABLE:
ALTER TABLE my_view ALTER COLUMN view_column DEFAULT expr;
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
creates an NOT NULL column with null values in it!
Because it hasn't got any other value to put in it. Try:
ALTER TABLE test ADD COLUMN id3 integer NOT NULL default 0;
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t make sense to back-patch the default parser for 8.4? At present,
it can't handle underscores in file-paths.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander wrote:
Did you ever post the code to anybody other than Gevik? If not, please
send it to pgsql-www and someone can give it a quick look-over (perhaps
Oleg can help us there?)
Will do.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers
ut together a custom parser that allowed underscore in words, but
given my extensive "C" experience in the last decade (one tsearch
parser) you don't want to just plug that into the live site. Someone
(Gevik?) was going to have a look at it when they had the time, but I'd
guess
Richard Huxton wrote:
Hmm - that does seem to be the case. I added a line to print "connstr"
along with the "."
waiting for server to startdbname=postgres port=5483 -i
connect_timeout=5.
The code looks fine to my uneducated eye though (bin/pg_ctl/pg_ctl.c
test_p
Richard Huxton wrote:
Tatsuo Ishii wrote:
Hi,
I have encountered a strange pg_ctl's behavior in 8.3.
pg_ctl -w -o "-p 5432" start<-- works
pg_ctl -w -o "-i" start<-- works
pg_ctl -w -o "-p 5432 -i" start<-- doesn't work
In t
aster starts successfully, pg_ctl keeps
trying to make sure that postmaster actually started and continues to
print "...".
It's not getting confused and thinking the port is "5432 -i" is it? I
tried "-i -p 5432" and that seemed to work.
--
Richard Huxton
Ar
Teodor Sigaev wrote:
So - is this a bug, feature, "feature"?
It's definitely a bug:
select count(*), query from queries group by query;
count | query
---+--
3 | 'tender'
4 | 'tender'
4 | 'tender'
(3 rows)
Will fix
rds it does the right thing. It also works fine with a
pl/pgsql function - presumably it's all down to context on the initial
parse.
I can't think of a way to exploit this maliciously, or do anything other
than cause a little confusion, but I'm not sure it's intentional.
to| 'tender' (2 clauses)
519 | tender & to | 'tender' (2 clauses)
557 | tenders & be| 'tender' (2 clauses)
736 | tenderer| 'tender' (1 clause)
749 | tender | 'tender' (1 clause)
869
f | f
999 | or || f | f
998 | requests | 'request' | f | t
997 | site | 'site' | f | t
996 | document | 'document' | f | t
(5 rows)
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing lis
[EMAIL PROTECTED] wrote:
I have the following table:
The hackers list is for development of the PostgreSQL database itself.
Please try reposting on the general or sql mailing lists.
--
Richard Huxton
Archonet Ltd
---(end of broadcast
n of the corresponding token-type.
To add a new token-type, I'd add it to the various lists line 30-194,
then add the relevant TParserStateActionItems.
Thanks
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 9: In versions belo
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Would there be any support for two changes in 8.4 though?
1. Tag tsvector/tsquery's with the (oid of) their configuration?
2. Either warn or require CASCADE on changes to a
configuration/dictionary that could impa
pt=false. That change is OK (as long as you don't
mind rogue tokens in your tsvectors) but others are probably not.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
ro.ru/sql5.11.3.ppt to explain ideas.
More details are described below.
Were you looking to hire developers, or do you have customers who are
looking to hire developers?
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 7: You c
1 - 100 of 353 matches
Mail list logo
