using savepoints is wrong.Please advice.
Thanks
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mar 12, 8:11 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
> Please always ensure that the list is copied on replies (use "Reply to
> all") so that other people can help you.
>
> sam escribió:
>
> > On Mar 11, 5:39 pm, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
&g
On Mar 12, 3:31 pm, sam <[EMAIL PROTECTED]> wrote:
> On Mar 12, 8:11 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
>
>
>
> > Please always ensure that the list is copied on replies (use "Reply to
> > all") so that other people can help you.
>
> >
postgres slow in doing updates on
large tables or is it because of the function call within the loop???
Thanks
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mar 27, 8:28 am, [EMAIL PROTECTED] ("Albe Laurenz") wrote:
> sam wrote:
> > Iam trying to update a database table with approx 45000 rows. Iam not
> > updating all rows at a time. Iam updating 60 rows at a given time for
> > example. and this is happening in a FO
;
Is is beacuse of the REVERSE command? or because the program is
executiung many select and update statements?
Catching the exception isnt helping here either.Can anyone explain me
why this error occurs and what i can do to resolve it?
Thanks
Sam
--
Sent via pgsql-general mailing lis
suggestions?
Thanks
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi,
I am a web developer, I've been using postgesql for a few years but
administratively I am a novice.
A particular web application I am working has a staging version
running one a vps, and a production version running on another vps.
They both get about the same usage, but the production versio
ary is (/usr/local/pgsql/lib/tsearch). But when I try the
psql ftstest <
tsearch2.sql
again, I get errors like 'errorsec not found in
tsearch2.so' or something like that.
Please help me out!
- Sam
e turning things around
so they fit this structure. Are there standard solutions to this that
work better?
Thanks,
Sam
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Tue, Oct 09, 2007 at 10:30:15AM -0500, Erik Jones wrote:
>On Oct 9, 2007, at 9:38 AM, Sam Mason wrote:
>> CREATE TABLE circle ( id SERIAL PRIMARY KEY, radius REAL NOT NULL );
>> CREATE TABLE square ( id SERIAL PRIMARY KEY, sidelen REAL NOT NULL );
>>
>> CREA
27;t allow me to work
with work with more complicated structures. I'll try and think up a
better example and send it along to the list when I can describe it.
Thanks,
Sam
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, ple
On Wed, Oct 10, 2007 at 12:10:10PM -0500, Erik Jones wrote:
> On Oct 10, 2007, at 11:42 AM, Sam Mason wrote:
>> On Wed, Oct 10, 2007 at 05:02:36PM +0100, Ian Barber wrote:
>>> CREATE TABLE shapes (
>>> shape_id serial PRIMARY KEY,
>>> area real not nul
ant.
A real programming language server side would be great though!
Sam
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
e queries. Generally, you want to split the information
that the database uses into one piece per column. If you do split it
then you could do something like:
WHERE d.year_min <= 2004 AND d.year_max >= 2002
Sam
---(end of broadcast)---
question probably doesn't help Lee, but what do the *recv (i.e.
float8 float8recv(internal)) functions do? Is this just used to receive
things from the client over the wire, or could they be used somehow
here.
Thanks,
Sam
---(end of broadcast)---
select sku, dept, (col1 + col2) * col3) from table group by dept
What are you expecting the group by to do here? It may be helpful if
you show what you expect the output to be.
Sam
---(end of broadcast)---
TIP 1: if posting/reading through Usenet,
) AS total
at the end, or maybe a mean (AVG) or standard deviation (STDDEV) if it
makes sense to do anything like that.
Sam
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
time you can just quickly move everything over.
Sam
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
r. I've not tried this on a large dataset, so I'm not sure what
sort of performance characteristics you should expect.
Sam
---(end of broadcast)---
TIP 6: explain analyze is your friend
D LOOP;
RETURN out;
END;
$$ LANGUAGE PLPGSQL;
It seems to work for me, but as a side effect will leave the array sorted
in the same order as the first parameter and with any duplicates it has.
Even more annoyingly if there is no intersection it will return NULL
instead of an empty arra
= ANY (array2)) AND NOT array1[i] = ANY (out) THEN
out := array_append(out,array1[i]);
END IF;
END LOOP;
RETURN out;
END;
$$ LANGUAGE PLPGSQL;
Sam
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, p
8.1.x but in 8.2.x it's
v = ANY ('{1,2}')
I don't have an 8.1 box so I can't test unfortunatly.
Sam
[1]
http://www.postgresql.org/docs/8.1/static/functions-comparisons.html#AEN13394
[2]
http://www.postgresql.org/docs/8.2/static/functions-comparisons.html#AEN141
more elegant. I've never seen generate_series used
like that, it's a very nice way of doing things. If your arrays are
ever more than a few elements long his is probably going to be much
faster. Generally for less than 6 or 7 elements it's better doing the
naive thing,
re there any thoughts of deferring index update so that many rows
can be merged simultaneously, rather than doing many individual index
operations? It sounds as though this is what Thomas is really after and
it would also remove the need for dropping indexes while doing a bulk
insert of data. I ap
cture.
I have a feeling you may have thought about this before, but thought it
wouldn't hurt to point it out more explicitly.
Sam
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
On Fri, Oct 26, 2007 at 02:21:39PM +0100, Gregory Stark wrote:
> "Sam Mason" <[EMAIL PROTECTED]> writes:
> > I think the lookup that is being referred to is the fact that if you've
> > got 55k (plus) files in a directory then the filesystem still has to
>
of the database totally but I can't host these applications for all of
> my customers.
In absolute terms you can't protect code. The whole point of computers
and information is that it's very difficult to lock down. Witness the
trouble that the big media companies are having with t
help to clarify what's going
on when you call a "function" in an impure language.
Sam
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED]
ave indexes out until I know that I need them. Indexes
are, after all, just a performance hack and therefore the root of all
evil! :)
Sam
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
a table.
Do you really want to disable the foreign key constraint, or just defer
their checking till you commit the transaction? If you just want to
defer checking, then [1] may help.
Sam
[1] http://www.postgresql.org/docs/current/static/sql-set-constraints.html
--
Open "DSN=badgerstudy"
Set rs = con.Execute("SELECT 1, 'foo'::TEXT, 'bar'")
While Not rs.EOF
rs.MoveNext
Wend
End Sub
Thanks,
Sam
---(end of broadcast)---
TIP 6: explain analyze is your friend
long as the kernel supports PAE that should be enough to make use of it.
You only need a 64bit address space when each process wants to see more
than ~3GB of RAM.
Sam
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Mon, Nov 12, 2007 at 11:31:59AM -0600, Scott Marlowe wrote:
> On Nov 12, 2007 11:29 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
> > You don't need a 32bit kernel to support 8GB of memory should you? As
> > long as the kernel supports PAE that should be enough to make use
On Mon, Nov 12, 2007 at 11:46:12AM -0600, Scott Marlowe wrote:
> On Nov 12, 2007 11:37 AM, Sam Mason <[EMAIL PROTECTED]> wrote:
> > And what's the performance hit of using native 64bit code? I'd guess
> > similar, moving twice as much data around with each point
On Mon, Nov 12, 2007 at 05:02:52PM -0500, Vivek Khera wrote:
> On Nov 12, 2007, at 12:29 PM, Sam Mason wrote:
> >You only need a 64bit address space when each process wants to see
> >more than ~3GB of RAM.
>
> And how exactly do you get that on a 32-bit CPU?
I didn't
ted into them. i.e. your FIFO will only act like a
FIFO until you VACUUM it, then all hell will break loose.
Sam
p.s. the test I did, was to run this once:
CREATE TABLE foo (
id serial,
value INTEGER
);
and then run several iterations of:
INSERT INTO foo (value)
SELEC
criterion for
> your delete? I mean, how else are you getting those row numbers in Oracle.
Yup, that's what I'm confused about as well.
> They have to be sorted somehow, unless you're just deleting 2million random
> records.
To be fair; they're n
them. When you're writing queries that use the
table, then you have to do lots of OUTER JOIN's to get everything you
need together. I asked about this a few weeks ago, but never got any
suggestions about better ways to do things.
Sam
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
;t put an IMMUTABLE
expression into a LIMIT or OFFSET. The query could be planned, by
ignoring the LIMIT and OFFSET, and then when the actual query was
executed they would be evaluated and the results fed into the right
places. I guess it's not been a problem before so nob
erently than
if it's returning lots of rows. Therefore, knowing what the LIMIT is,
at planning time, makes a lot of difference. How would this work in the
presence of arbitrary expressions for LIMIT?
Sam
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Thu, Nov 15, 2007 at 07:46:46PM +0530, ??? ??
wrote:
> On Nov 15, 2007 5:52 PM, Sam Mason <[EMAIL PROTECTED]> wrote:
> > What I tend to do here, is something like:
> >
> > CREATE TABLE test (
> > type INTEGER,
> >
This basically goes back to the fundamental issue that a relation has no
implicit order (it sounds as though Oracle had an implicit one, but that
assumption doesn't hold with PG or in general).
Maybe partitioning could help here.
Sam
---(end of broadcast)--
On Thu, Nov 15, 2007 at 07:28:17PM +, Richard Huxton wrote:
> Reg Me Please wrote:
> >As Sam says I should be able to "put an IMMUTABLE expression into
> >a LIMIT or OFFSET". And under some circumstances (SQL function
> >body) it's true even with VAR
uced in 8.2, i.e. something like:
SELECT COUNT(*) FROM (
DELETE FROM foo RETURNING 1) x;
However PG doesn't seem to support this. It seems logical to support
this construct now that RETURNING has been incorporated. There's
probably something obvious that I'
ly have a serial column as the primary key,
and a UNIQUE index on those six fields. Depends on what you're doing,
though unless you've got a few years experience I'd be tempted to stay
away from primary keys of more than a single column.
Sam
-
( Fi Fie Foe Fum, I smell the blood of a religious war )
On Fri, Nov 16, 2007 at 01:03:23PM -0600, Ron Johnson wrote:
> On 11/16/07 12:54, Sam Mason wrote:
> > On Fri, Nov 16, 2007 at 03:50:20PM -0300, Jo??o Paulo Zavanela wrote:
> >> How many fields is recomended to cr
-+---
> IsActive| boolean |
If you don't enclose an identifier in double quotes (") then PG will
make the identifier lowercase before looking for it. This is in an
attempt to support case-insensitive general usage, while still allowing
case-sensitive usage if you r
of changing things around like this.
There are lots of things that seems as though they'll be pretty awkard
to do, I'm sure it's just because I haven't thought about it enough.
Sam
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Fri, Nov 16, 2007 at 12:51:07PM +, Raymond O'Donnell wrote:
> On 16/11/2007 10:02, Sam Mason wrote:
>
> > SELECT COUNT(*) FROM (
> >DELETE FROM foo RETURNING 1) x;
>
> I haven't played with this yet, but AFAICS this will simply return the
>
with a strange interaction with
connection pooling.
Sam
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Fri, Nov 16, 2007 at 01:38:30AM -0500, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > wow, that's kind of fun isn't it. I only thought you could put a
> > constant in there. Maybe I should have had a look in the grammar/tested
> > it first!
&
On Fri, Nov 16, 2007 at 01:34:40PM -0500, Greg Smith wrote:
> On Fri, 16 Nov 2007, Sam Mason wrote:
> >Just out of interest, what does EAL level 1 actually test/check for?
>
> There's a good summary of this whole process on the relevant Wikipedia
> pages:
>
>
me that it was a very specific set of use cases, but it may be
something more generally useful.
Sam
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED
On Fri, Nov 16, 2007 at 04:41:42PM -0500, Merlin Moncure wrote:
> On Nov 16, 2007 3:21 PM, Sam Mason <[EMAIL PROTECTED]> wrote:
> > On Fri, Nov 16, 2007 at 12:06:46PM -0800, Joshua D. Drake wrote:
> > > When that is needed I do this:
> > >
> > > create
one style
exclusively is almost certainly bad, but having a preference for one or
the other is probably good as it'll make the database as a whole more
cohesive and subsequently ease maintenance.
Comments?
Sam
---(end of broadcast)---
TIP 6: explain analyze is your friend
it generally matters much
more, but people are generally a bit more flexible.
Sam
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
-> 2007-11-19 15:46:09+00
That just ignores the AM/PM flag, which may or may not be what you want
to do.
Sam
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
On Mon, Nov 19, 2007 at 06:03:36PM +0100, Dragan Matic wrote:
> Sam Mason wrote:
> >On Mon, Nov 19, 2007 at 04:52:10PM +0100, Dragan Matic wrote:
> >
> >>select * from table where timestamp_column < '11/19/2007 15:46:09 PM'
> >>
> >
e is wrong. For the abstractions inside the database
natural keys make a lot of sense.
Sam
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
d guess you're calling it like:
SELECT get_items2();
whereas, you should call set returning functions like:
SELECT * FROM get_items2();
Sam
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
> Is there somewhere in the docs that I should have found this (and other
> useful) functions?
I find the following tool helpful:
http://doxygen.postgresql.org/
Sam
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
onable way you'd need to some sort of regression; i.e. you'd need
to consider all the relavant data and then try and minimise the total
error somehow. I've always relied on external tools to do this sort of
thing, but if you want to do it in the database you may be able to get
somewhe
ous example this was easy as all you wanted was a
set of numbers. Now you want the cartesian product of this series and
something else. So you need to be doing something like:
SELECT x.i, x.j, COUNT(t.k)
FROM (SELECT DISTINCT t.i,s.j FROM table t, generate_series(1,7) s(
ult in PG. You've got
a few ways of fixing things then. Tell MS-SQL to do the same, write a
sed script to do the translation, or use the "NULL AS 'NULL'" option in
the COPY command.
Sam
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
en able to design most of the programs I work on as
relatively simple layers over a database, I'm not sure if you're able to
work like this.
Sam
---(end of broadcast)---
TIP 6: explain analyze is your friend
to choose a suitable set of abstractions, it
helps for the designer to know the ins and outs of the tools being
used. I was trying to encourage Colin to look at using databases
in a different way, different styles of programming suit different
applications and hiding the database can have detrim
tion
> 2) pid
the value in itemprop is non-null
> 3) hey today I'm hungry as usual
the value in itemprop is null. use something like this to get the
current values for an item:
SELECT i.itemname, i.propname,
coalesce(i.value,p.defvalue) AS curval
FROM itemprops i, props p
WHERE i.propname = p.name
AND i.itemname = 'desk';
Spelling out identifiers with longer names really helps *a lot* when
you're an outsider trying to understand someones code. It also
short-circuits a lot of the ambiguity that will inevitably exist in the
description.
Sam
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
> I would assume that hash indexes have inbuilt mechanisms for collision
> checking before returning the row as a match. Am I correct in this
> assumption?
The above isn't using hash indexes in any way. You're creating a b-tree
index on top of the md5-hash of a column. The on
LEFT JOIN o_3 o3 ON c.o3id = o3.id;
Not too bad though.
Sam
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
('2001-1-1','2001-12-31'),
('2002-1-1','2002-12-31')) d(mn,mx)
WHERE x.date BETWEEN d.mn AND d.mx
AND x.id IN (5,6,7,8)
GROUP BY x.tbl, d.mn
ORDER BY x.tbl, d.mn;
Sam
---(end of broadcast)---
TIP 6: explain analyze is your friend
rn TRUE as I'd expect them to, but the
second count doesn't return 0.
The Comparison Operator docs[1] describe the behaviour of IS NULL
changing, with respect to records, in version 8.2. Is count still
exhibiting the old behaviour?
Sam
[1] http://www.postgresql.org/docs/
On Mon, Jan 28, 2008 at 04:38:01PM -0500, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > I've just noticed that the handling of COUNT(record) and (record IS
> > NULL) aren't consistent with my understanding of them. If I run the
> > following
On Tue, Jan 29, 2008 at 06:04:48PM +0100, Ivan Sergio Borgonovo wrote:
> select
> case
> when (a>3) then a*b
> when (a<3) then a+b
> end as pippo
> where pippo<12;
I've tended to do:
SELECT *
FROM (
SELECT "complicated expression"
27;re looking for is "UPSERT", the following looks relevant:
http://stackoverflow.com/questions/1109061/insert-on-duplicate-update-postgresql
--
Sam http://samason.me.uk/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
essage(conn));
PQclear(res);
exit_nicely(conn);
}
PQclear(res);
}
finish = get_wall_time();
fprintf(stderr, "raw %f \n", (finish-start));
/* close the connection to the database and cleanup */
PQfinish(conn);
return 0;
}
```
Results:
```text
sam@ubuntu
he.c', I thought that the
decision of the plan to use was purely based on the value sent in to
the prepared query. However it seems that the planner completely
ignores the value in some steps. (so, for example I was thinking that
"aaa" and "ccc" would result in completely diff
One interesting option would be kicking in an extra more expensive
planning cycle after the Nth run of the query, in general a lot of
these planned queries run 1000s of times, if you add some extra cost
to run 100 it may not be prohibitive cost wise.
On Tue, Nov 18, 2014 at 8:27 AM, Tom Lane wrot
I have this query:
select * from topics
order by case when id=1 then 0 else 1 end, bumped_at desc
limit 30
It works fine, bumps id 1 to the front of the sort fine but is
terribly inefficient and scans
OTH
"select * from topics where id = 1" is super fast
"select * from topics order by bumped_a
Note: I still consider this a bug/missing feature of sorts since the
planner could do better here, and there is no real clean way of
structuring a query to perform efficiently here, which is why I
erroneously cross posted this to hacker initially:
# create table testing(id serial primary key, dat
(4 rows)
I need to be able to offset and limit the union hack in a view, which
is proving very tricky.
On Wed, Feb 4, 2015 at 9:15 PM, BladeOfLight16 wrote:
> On Tue, Feb 3, 2015 at 11:28 PM, Sam Saffron wrote:
>>
>> Note: I still consider this a bug/missing feature of sorts since
sure that a new
master could be correctly selected (or that the synchronous slave is
also uncontactable, meaning we can't promote a new master without
risking data loss). Is there some mechanism for finding this that I've
missed, or some other way around this problem?
Thanks,
Sam Cra
I have this query that is not picking the right index unless I hard code dates:
SELECT "topics".* FROM "topics"
WHERE topics.last_unread_at >= '2017-05-11 20:56:24'
"Index Scan using index_topics_on_last_unread_at on topics
(cost=0.41..8.43 rows=1 width=725) (actual time=0.005..0.065 rows=5
loop
Awesome, thanks! I will give that a shot
On Wed, 24 May 2017 at 6:14 pm, Tom Lane wrote:
> Jeff Janes writes:
> > On Wed, May 24, 2017 at 1:42 PM, Sam Saffron
> wrote:
> >> I have this query that is not picking the right index unless I hard code
> >> dates:
OK, I committed a fix to Discourse, the suggested pattern by Tom works
like a charm, in my particular user case it cuts a query down from
200-500ms to 8ms.
Thank you heaps
https://github.com/discourse/discourse/commit/29fac1ac18acdc1f0d2c1650d33d2d4a1aab0a0b
On Wed, May 24, 2017 at 6:33 PM, Sam
psql 9.6.3 on OS X.
I'm dealing with a production database in which all db access has been made
by the same user - the db owner, which isn't actually a superuser because
the db runs on amazon RDS - amazon retains the superuser privilege for its
own users and makes non-superuser role with createrol
levate their role
first, in which case reassign owned will come in handy for non-superuser
roles - cleaning up their mistake.
--sam
On Fri, Oct 13, 2017 at 12:39 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Fri, Oct 13, 2017 at 6:04 AM, Alvaro Herrera
> wrote:
>
On Tue, Jan 29, 2008 at 06:49:50PM +0100, Ivan Sergio Borgonovo wrote:
> On Tue, 29 Jan 2008 17:17:39 +0000 Sam Mason <[EMAIL PROTECTED]> wrote:
> > I've tended to do:
> >
> > SELECT *
> > FROM (
> > SELECT "complicated expression" A
M table2 WHERE id = n;
>
> This is working alright.
> So the problem should lie in the last part:
>
> from table2, table3
> where table2.id = table3.id
> and table2.id = n;
>
> I think I need the UNION statement instead?
Did you try something similar to the code I
TEGER PRIMARY KEY, value TEXT );
CREATE TABLE b ( idx INTEGER PRIMARY KEY, value TEXT );
"idx" being your "i" above. It's then trivial to do:
SELECT COALESCE(a.idx,b.idx) AS idx,
a.value AS a, b.value AS b
FROM a FULL OUTER JOIN b USING (idx);
to get all the v
xlog_switch as
> select '0123456789ABCDE' from generate_series(1,100);
> drop table xlog_switch;
Just out of interest, why doesn't it do the following?
BEGIN;
create table xlog_switch as
select '0123456789ABCDE' from generate_series(1,100);
ROLLBACK;
Thank
ckly, sometimes it can be a very different
plan.
> I think it will still process all the rows and return just one.
How do you explain that when you run:
SELECT 1/v FROM (VALUES (1),(0)) c(v);
Without a limit you get a "division by zero" exception, and when you
have a limit of one r
it will grab the current paragraph
and send it off to psql, showing the results in another window. Once
I'm happy with the statement I leave it and move on to the next job
(committing changes to some SCM when appropriate).
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgres
= 1;
Or you could do something completely different!
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
rs actually want though!
I think the hypothesis would be something along the lines of comparing
developer and project requirements with the choice of database
implementation. Comments? I was thinking of sending it to other FOSS
database mailing lists as I'm not sure how to contact commerci
I.e. get the regressions working in plain R using data
extracted by hand before trying to do everything in PG.
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
bly does. For example, PG
would be quite happy giving back one row per year if that's all your
processor(s) were capable of. Your users may be a little unhappy with
this though!
What are you doing and what hardware have you tried it on?
Sam
--
Sent via pgsql-general mailing list (p
he query builder that Access
provides is enough. If neither you or your users are accustomed to
Access then I'd probably look elsewhere.
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
rectly expressed.
My current favourite is capability based security, it allows you to
directly say that "auditors" have transitively read-only access to
specific things (i.e. the entire database).
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
very fancy you
don't want the execute either. You can just put normal SQL statements
in the code and they'll get run as normal, expanding variables when
needed.
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
1 - 100 of 812 matches
Mail list logo
