, but I can't figure out the
command line needed.
--
Sam http://samason.me.uk/
[1] http://docs.python.org/library/codecs.html
[2] http://www.gnu.org/software/libiconv/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
On Tue, Oct 13, 2009 at 10:22:04PM +, Tim Landscheidt wrote:
Sam Mason s...@samason.me.uk wrote:
Calculating (C - B) / C isn't easy for timestamps, whereas it's easy
for dates. I believe this is why there's a specific version for the
former but not the latter.
(I obviously meant (B
for this case to be an error, though
it would be more in line with PG throwing errors when you asked for
something bad instead of making a best guess.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
[2,3,4,5,6];
if you provided the appropriate operators. If you use a fixed sized
tuple, as above, you'd get errors if you tried to use points of the
wrong dimensionality.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
is an authority you probably don't want to go
spreading too widely and hence is limited to userusers.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
+ $xn + FROM PUBLIC;
GRANT SELECT ON TABLE + $xn + TO PUBLIC;
);
This wouldn't help much here, but may in more complicated bits of code.
--
Sam http://samason.me.uk/
[1]
http://docs.python.org/reference/lexical_analysis.html#string-literal-concatenation
--
Sent via pgsql
decision.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
..if for small changes it creates 16 mb files then storing them
will eat up lot many space.
I think the following utility would help you here:
http://pgfoundry.org/projects/clearxlogtail/
Also I'd recommend reading the articles Alban pointed to, it can be
somewhat tricky to backup PG correctly.
--
Sam
really can't do this, how about using ALTER USER to change the
the user that they use latin1 by default?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
tenant.
The term for this that tends to float around for this concept (in PG
anyway) is gap-less sequences: this looks like a reasonable link:
http://www.varlena.com/GeneralBits/130.php
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
On Mon, Oct 05, 2009 at 12:03:38AM +, Tim Landscheidt wrote:
Sam Mason s...@samason.me.uk wrote:
Tim Landscheidt wrote:
generate_series(A, B, C) can also
be written as A + generate_series(0, (C - B) / C) * C
If you can figure out the limit then it seems easy,
though I'm not sure
; as it says this can
happen because the server has crashed. To figure out what really
happened, you want to look at postgres' logs on the server.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
will! :)
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
, but
may not here:
http://www.postgresql.org/docs/current/static/sql-altertable.html
Something like:
alter table session_allocation_info alter status set statistics 200;
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
On Sun, Oct 04, 2009 at 11:08:01AM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Sun, Oct 04, 2009 at 01:44:30AM -0700, tomrevam wrote:
- Bitmap Index Scan on session_allocation_info_status_idx
(cost=0.00..5.28 rows=1 width=0) (actual time=1619.652..1619.652
rows=51025
precision. Support for currencies such as yen
also dictates that reasonably large numbers are supported
Which limits do you find to be problematic in PG?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
On Sun, Oct 04, 2009 at 09:31:02AM -0700, Rich Shepard wrote:
On Sun, 4 Oct 2009, Sam Mason wrote:
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. without a loss of precision as
you put it).
I've not followed this tread
On Fri, Oct 02, 2009 at 09:48:14PM +, Tim Landscheidt wrote:
Sam Mason s...@samason.me.uk wrote:
8.4 has a generate_series(timestamp,timestamp,interval) which would seem
to be a bit more flexible than you want.
Yes, I know :-). But as generate_series(A, B, C) can also
be written
number at the end---i.e. 10 orders of something cost the same as
one order of 10 items. Or you set the precision to be coarser and then
the values that have been rounded off will match everything else.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general
On Sat, Oct 03, 2009 at 11:49:50AM -0400, Merlin Moncure wrote:
On Sat, Oct 3, 2009 at 11:40 AM, Sam Mason s...@samason.me.uk wrote:
it's still a computer and thus can't represent anything
with infinite precision (just numeric fractions in PG's case, let alone
irrational numbers).
I
datatypes, it seems much easier to just provide a standard set of domain
specific functions that are explicitly used by the user. The SQL
standard specifies that they need to exist so PG has to support them,
but their purpose still confuses me!
--
Sam http://samason.me.uk/
--
Sent via pgsql
place. I have a feeling I may have used the functionality once, but
I can't think why or for what now. Having a function seems just as
expressive to me, which is why I think I'm missing the point.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
that you'd always have to implement GROUP BY
by doing a sort step first then I can see why they'd end up with this.
But if you want to do *anything* else (i.e. hash aggregate in PG) then
you want to keep the semantics of GROUP BY and ORDER BY separate as the
spec and indeed PG does.
--
Sam http
On Sat, Oct 03, 2009 at 04:14:21PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
the decision to officially bless some code as being a cast
rather than just a function seems very arbitrary
It's useful when the conversion semantics are sufficiently natural that
you want
it, and bit shifting up to 32 bit was crazy fast.
Just out of interest; have you tried PG's support of fancier index
types? HStore or intarray would appear to help with what you're doing.
Not quite sure what you're actually doing so my guess could be a long
way off!
--
Sam http
want.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
, this could be made more efficient; whether it's worth it is a
difficult question!
And does its storage as a byte affect indexing or query planning?
Not sure which aspects you're referring to here, sorry.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general
thing either way so performance shouldn't be
affected.
Hope that helps!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to be commited and then
someone does a quit on your session..all your work is lost
I'm not sure what you're saying here. These are normal transactional
semantics and are what all ACID databases are specified to do. You need
to issue a COMMIT for data to be committed.
--
Sam http://samason.me.uk
doesn't seem like correct behavior and will generally come back and bite
you later on---for example, what if the user really does want to insert
a NULL value into *any* column that has a non-NULL DEFAULT value.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general
to the same name as the old one
repeat this for all indexes.
Why not just do:
REINDEX TABLE yourbigtable;
No need to worry about rebuilding foreign key constraints or anything
like that then.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general
On Tue, Sep 29, 2009 at 03:13:49PM +0200, Brian Modra wrote:
2009/9/29 Sam Mason s...@samason.me.uk:
Plain vacuum should allow things to reach a steady state after
a while,
If there are a lot of deletes, then likely the index parameters are
not the best.
My interpretation of the OPs
(''' || new::text || '''::foo).*';
it wants to be closer to:
execute 'insert into foo_something select (foo ' || quote_literal(new) ||
').*;';
but it's a bit fiddly and I may have got that wrong somewhere else.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql
On Tue, Sep 29, 2009 at 08:45:55AM -0700, Alan Hodgson wrote:
On Tuesday 29 September 2009, Sam Mason s...@samason.me.uk wrote:
it's faster is because
parsing CSV data is easier than parsing SQL.
At least I think that's the only difference; anybody know better?
I think a big reason
On Tue, Sep 29, 2009 at 06:30:42PM +0200, Pavel Stehule wrote:
2009/9/29 Sam Mason s...@samason.me.uk:
I may have got that wrong somewhere else.
I afraid so this technique is very buggy. You need unpacked serialised
record.
Hum, I'm not sure what an unpacked serialised record is or why I'd
On Tue, Sep 29, 2009 at 09:11:19AM -0700, Alan Hodgson wrote:
On Tuesday 29 September 2009, Sam Mason s...@samason.me.uk wrote:
I'm pretty sure you can send multiple statements in a
single round trip. libpq is defined to work in such cases anyway:
http://www.postgresql.org/docs/current
On Tue, Sep 29, 2009 at 12:17:51PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Tue, Sep 29, 2009 at 08:45:55AM -0700, Alan Hodgson wrote:
I think a big reason is also that the client can stream the data without
waiting for a network round trip ack on every statement
because
it has to pull the whole block in?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to be useful?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
commands, you can certainly generate a COPY command to insert the same
data. The advantage is a large drop in parse time for inserting larger
numbers of rows. As you're saying you want to insert 500 rows, I'd
suggest at least trying to get COPY working.
--
Sam http://samason.me.uk/
--
Sent
/
would help. I can't see anything about COPY support, but it should help
with other things.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
with the RDBMS Encryption (PostgreSQL in my case) and the Host OS
password encryption method.
Yup, as far as I can tell this shouldn't have any effect. Then again,
I don't use SuSE and it's possible (though very unlikely) that they
changed this.
Sam
--
Sam http://samason.me.uk/
--
Sent
of performance do your disks give you and at what rate is PG doing
sequential scans for you?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
about PG. If I can read at 90MB/s from a single
stock SATA drive you should be almost hitting 200MB/s with this, or
300MB/s in a RAID1 across three drives.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
On Sun, Sep 27, 2009 at 10:01:27PM +0100, Sam Mason wrote:
Tested by turning on \timing mode in psql, dropping
caches and running:
SELECT 715833344 / 7597.216 / 1024;
Help, I can't do maths! This is overestimating the performance and
should be:
SELECT 715833344 / 7597.216 / 1024 / 1024
it, but I have a feeling it may be
easier to side-step the problem somehow.
That all got a bit longer than I was expecting, but I hope it's useful!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
that
it was because ports were at a different level of abstraction. This
mailing list is good for otherwise obscure details like that!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On Fri, Sep 25, 2009 at 11:01:02AM -0700, Ron Mayer wrote:
Sam Mason wrote:
It all depends on the problem domain of course, but this seems to work
OK for us! I really want to hack Samba around so that the users can
view the files directly from inside the database, but I'm not sure how
version. When you need to push the changes out, just push out the WAL
updates, dump the live version, copy the master into a new live
version and then replay the new WAL records.
Depends on how much disk space you have I guess.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing
revision and then you'll know whether EAV
really fits.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
.5432.
Maybe you want -P to be asking for the password?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Sep 24, 2009 at 07:57:55PM +0100, Sam Mason wrote:
postg...@sussy:/root createuser -D -p ricky
I don't think you want to be passing -p here; it's saying to use
ricky as the port number, which fails (sounds like a bug if it doesn't
complain about this) giving a port number of zero
. There are plans to change this for pg_hba.conf, but you'll
have to wait a bit before that happens.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
);
?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
native to the database?
If they're validated inside the database then it's going to be done by a
DB admin anyway, or am I missing something? If they're done by the DB
admin, isn't it easy to just use the tools they're used to?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing
.connect(dbname='db1');
cur = conn.cursor();
cur.execute (select count(*) from table;);
[[n]] = cur.fetchall();
It's a bit of a fiddle to change over, but having a something more
expressive than a bourne shell can help.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing
but the most trivial code has to go out of its way to
be correct with respect to this.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
in the ON clause.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
it before.
Sounds valid, though the general mantra here is that PG knows best. Is
that always true?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the filesystem, which is what UTL_FILE seems to be about
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Sep 17, 2009 at 03:56:09PM -0400, Alan McKay wrote:
Our databases are pretty big, and our queries pretty complex.
How big is big and how complex is complex?
An EXPLAIN (EXPLAIN ANALYSE if it's not going to hurt things) of some of
your common queries would help a lot here.
--
Sam
probably save a bit
of face, but I'd wait a bit for that as well.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[ crap, that wasn't supposed to go to the list ]
On Wed, Sep 16, 2009 at 06:30:46PM +0100, Sam Mason wrote:
Martin, *please* stop responding publicly to this thread
I'm feeling very embarrassed now!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general
unicodedata.normalize('NFKD', str.decode('UTF-8')).encode('UTF-8');
If you're converting from a utf8 encoding, you probably need to go
back again! This could certainly be made easier though, PG knows what
encoding its strings are stored in, why doesn't it work with unicode
strings by default?
--
Sam http
, but I can't defer those constraints (the
reason I'm asking for a non-check soln)
If this is to do with your similar questions from earlier; at what point
does the data become valid and why don't you just delay putting the data
into the real table at then.
--
Sam http://samason.me.uk
and I can't think how PKI would help here.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, Sep 14, 2009 at 12:17:55PM -0400, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
On Mon, Sep 14, 2009 at 05:45:14PM +0200, Saleem EDAH-TALLY wrote:
How can a user extract data from a container, by whatever
name we call it, if he does not have the key to open it ?
Exactly
to open it ?
Could you please instruct how to achieve this ?
Exactly the same way that libpq does--debuggers are powerful tools!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
which is a bit annoying, but
doesn't seem too hard in principle.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
thing to note is that PG tends to change the on-disk format
between major versions, where a major version is defined as the second
digit changing. 8.3 and 8.2 are different major versions and have
different on-disk formats, while 8.3.6 and 8.3.7 are not.
--
Sam http://samason.me.uk/
--
Sent
am asking is how do I order only by the date? -MM-DD?
Casting to a date first is probably easiest, date_trunc would also work;
so one of:
ORDER BY Event_Date::DATE, Name;
or
ORDER BY date_trunc('day',Event_Date), Name;
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing
[ please CC the mailing list and not the list owner, they answer
mailing list questions not PG questions ]
On Tue, Sep 08, 2009 at 10:31:50AM -0400, Jia Chen wrote:
Sam Mason wrote:
I don't think you need to go that far. I'd just do an initdb
somewhere on the removable disk and then start
.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
(
select array[2,3] as a
union
select array[3,4] as a ) x);
getting the resulting tuples out again is a bit of a struggle and you
may be better off with using a custom type. Have a look at CREATE
TYPE[1] for this.
--
Sam http://samason.me.uk/
[1] http://www.postgresql.org/docs/current
array[2,3]
UNION ALL
SELECT array[3,4]) x(a));
and it should do the right thing in 8.3.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to do slow things. It looks
somewhat strange as well, do you really want to join *every* row in
tab_main to *every* row in tab_user when tab_main.kind doesn't
equal zero?
Maybe if you could describe what you want to do in English then the
query would make a bit more sense.
--
Sam http
SELECT array[3,4]) x(a))) x(arr);
If you really do care how the literals are formatted, then you're going
to have to come up with your own data type and associated input and
output functions.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general
of guides around on the internet; google is your friend!
Other than trying to rewrite your queries in different ways I'm not sure
what to suggest, it'll give you experience which is the important thing.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general
you? For
example, if you have a users table in schemas app1 and app2, you
can refer to the table in the first schema as:
SELECT uid, name
FROM app1.users;
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
=64)
- Seq Scan on t2 (cost=0.00..26.38 rows=1310 width=32)
Notice that the Merge Cond is working on the CASE expression in 8.4.
This is too late and is breaking things.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
On Tue, Sep 01, 2009 at 10:05:44AM +0100, Sam Mason wrote:
On Mon, Aug 31, 2009 at 04:02:43PM -0700, Sheng Cheng wrote:
I though the following query would give me the same results in 8.4.0 and
8.3.1.
It should give the same results! This looks like a bug in 8.4 to me
I've just noticed
://www.postgresql.org/docs/current/static/plpgsql.html
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
startdate TIMESTAMP DEFAULT now(),
ADD COLUMN enddate TIMESTAMP DEFAULT 'infinity';
COMMIT;
Not sure if that's the sort of thing that you want/need but I don't
think there's a general solution to the problem. Determining the
relevant context for this sort of thing is hard.
--
Sam http
it somewhat open, but wouldn't date_trunc be better here?
Something like:
SELECT * FROM the_table
WHERE date_trunc('week',the_date_column) =
date_trunc('week',CURRENT_TIMESTAMP);
Otherwise you'll end up getting values for other years as well as the
current one.
--
Sam http://samason.me.uk
.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
, you can do:
SELECT attname
FROM pg_attribute
WHERE attrelid = 'foo'::regclass;
Have a look here for docs:
http://www.postgresql.org/docs/current/static/catalogs.html
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On Wed, Aug 26, 2009 at 09:10:25AM -0700, Erwin Brandstetter wrote:
How do you import data from an xml-file?
If they're all that small, put the file into the database as is and then
use xpath[1] to pull it apart and turn it into something a database
understand.
--
Sam http://samason.me.uk
) doc_emp_key,
doc_date_created, doc_subject
FROM doc
ORDER BY doc_emp_key, doc_date_created DESC) d
ON e.emp_key = d.doc_emp_key
WHERE b.bpt_emp_key = e.emp_key
AND b.bpt_com_key = 22
AND b.bpt_status -1;
--
Sam http://samason.me.uk/
--
Sent via pgsql
TO in some cases but I'm a bit afraid of troubles
that may appear in the future.
I always tend to bracket things in an explicit BEGIN+COMMIT, why
wouldn't you do this?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
/download/windows
seems to point there. Maybe the link there from:
http://www.postgresql.org/download/
could be clearer somehow?
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Wed, Aug 26, 2009 at 08:58:17PM +0200, Magnus Hagander wrote:
On Wed, Aug 26, 2009 at 20:45, Sam Masons...@samason.me.uk wrote:
On Wed, Aug 26, 2009 at 08:11:58PM +0200, Thomas Kellerer wrote:
If one goes directly http://www.enterprisedb.com/products/pgbindownload.do
so they reflect the
structure of the data you're really putting in.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
about writing some C code
to get a GiST index going.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
on a diagonal or will they be
scattered randomly around. I.e the less correlation between the start
and end date the better GiST will do, relative to a btree index. I
think that's right anyway!
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
to its database to be synchronized every few hours. Is that
enough for development purposes? You could even pipe it through some
crypto code if you're worried about the data going missing.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
,fieldB,fieldC,fieldD)
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the generate_series call into a function so you
don't have to refer to myPkArray so many times.
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
))).*;
But this seems nasty and bumps up against the annoying record type has
not been registered that I hit all to often. More fiddling gets to:
CREATE TYPE foo AS ( i int, j int );
SELECT (id((SELECT (1,2)::foo))).*;
or am I missing something obvious?
--
Sam http://samason.me.uk/
--
Sent via pgsql
On Fri, Aug 21, 2009 at 10:49:52AM -0400, Merlin Moncure wrote:
On Fri, Aug 21, 2009 at 10:17 AM, Sam Masons...@samason.me.uk wrote:
CREATE TYPE foo AS ( i int, j int );
SELECT (id((SELECT (1,2)::foo))).*;
or am I missing something obvious?
I think that what you are bumping
201 - 300 of 808 matches
Mail list logo
