On Sat, Nov 4, 2017 at 6:41 PM, Marc-Olaf Jaschke wrote:
> Perhaps I misunderstand the discussion but would "INSERT .. ON CONFLICT DO
> SELECT [FOR ..]" not provide a solution for the following use case?
>
> [ .. ]
>
> That works. But it is a bit inconvenient to write the pseudo update clause.
>
On Wed, Mar 12, 2014 at 10:57:03AM +, matshyeq wrote:
> On Wed, Mar 12, 2014 at 9:30 AM, Marko Kreen wrote:
> > This option would not make sense as you are not "fetching" anything,
> > full resultset is being streamed from server over TCP connection.
>
> We
lue?
It could close connection in the middle of resultset but that seems like
bad idea. LIMIT N or FETCH N are better for such task.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e.html
> Finally, you will have a client-server round trip for each row returned.
> This is a problem you would also have when using PQsetSingleRowMode().
PQsetSingleRowMode() does not do additional roudtrips, it loads rows
from libpq internal buffer.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ll can have
3*90 server connections open.
The max_client_conn is meant for rescue limit when something is
completely broken and should not be hit in normal work. 4 would
be reasonable number...
With that many databases, you just need to accept you need few
connections to each db open, otherwise
rtext-equivalent, which means you can use them to log in,
without knowing the original password.
And the "encryption" is single md5() so the actual password
is relatively easy to crack too.
So avoiding logging them is good idea.
--
marko
--
Sent via pgsql-general mailing list (pg
iste3 in Debian experimental, but there are no
> 'modules' packages. Don't i need one anymore?
> (hope this is not off-topic for the list)
It's renamed to postgresql-X.Y-pgq3.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
It implements various unrelated features, but basics are in
find_table_info() which loads cached data and relcache_reset_cb()
which invalidates.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to destroy, and everything appears to
be working correctly.
Regards,
Marko Tiikkaja
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
eds to unconditionally clear the
surround SPI context, or why it assumes it's a good idea.
Regards,
Marko Tiikkaja
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
o correctly
clean up after an exception? The attached code tries to imitate what
the PLs are doing, but it's not working. :-(
Regards,
Marko Tiikkaja
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "postgres.h"
#include "
On Fri, Nov 16, 2012 at 11:09 AM, Sébastien Lardière
wrote:
> On 11/15/2012 08:40 PM, Cédric Villemain wrote:
>> top post: this looks like a plproxy bug (no ?), I've added Marko in CC.
>
> Yes, it is, i think …
Thanks, fixed in git. Fix will be in 2.5 release.
--
marko
ore
> complicated if you inserted the row in the same transaction.
This can be solved by storing txid_current() into row
and using that in comparision instead xmin/xmax.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Sat, Oct 6, 2012 at 5:24 AM, Adrian Klaver wrote:
> One thing I see above:
> http://pgbouncer.projects.postgresql.org/doc/config.html
> ""\*" acts as fallback database"
>
> Notice the backslash.
The backslash is asciidoc/docbook accident, it should be plain
res" ""
> "MYSITE_pgbouncer" ""
Because of data sanitizing I cannot see actual problem,
but few hints:
- Don't give one username several times (pgbouncer uses just one of them)
- Usernames are case-sensitive
- Username max length is 63 chars
--
marko
endencies between dbs.
- Non-transactional (remote call may commit, but local call may not)
- Not good idea if high transaction rate is expected
(Adds network latency to each call, many new connections)
2) Use PgQ ( http://wiki.postgresql.org/wiki/PGQ_Tutorial )
+ Good for high loads as it d
en dumping,
or later post-processing the dumps.
But it produces random values, if you need something
realistic-looking you need custom mapping logic.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, Jan 31, 2012 at 08:17:57AM +1100, Chris Angelico wrote:
> On Tue, Jan 31, 2012 at 4:12 AM, Marko Kreen wrote:
> > On Mon, Jan 9, 2012 at 5:58 AM, Chris Angelico wrote:
> >> http://wiki.postgresql.org/wiki/PGQ_Tutorial
> >>
> >> PGQ looks promising, b
uish in the database until one is
> started up).
PGQ does not lose events - after consumer registers
on the queue it is guaranteed to see all events.
So it's a matter of registering your consumers
before anything interesting happens in database.
The actual consumers do not need to be runnin
unds like you are using statement pooling - every statement can be
> assigned to a different server connection. You may need transaction pooling
> or session pooling:
>
> http://pgbouncer.projects.postgresql.org/doc/usage.html
Statement pooling throws error on open transaction.
--
marko
--
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, Dec 19, 2011 at 01:05:20PM +0100, Filip Rembiałkowski wrote:
> W dniu 19 grudnia 2011 10:39 użytkownik Marko Kreen
> napisał:
> > On Sat, Dec 17, 2011 at 10:25:40PM +0100, Filip Rembiałkowski wrote:
> >> Following scrip causes segmentation fault. Any ideas
db, or use
TARGET/SELECT to pick different target function.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
al give the vague error "no working server connection"?
"no working connection" means that client logged into pgbouncer successfully,
but pgbouncer cannot log into server.
Please look into Postrgres log file for details.
If you see no failures there, you have wrong connect st
lso keep in mind that bytea is double-quoted.
See the docs for details.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ands.
Don't do it without synchronizing with business logic...
> Maybe I should try session mode of pgbouncer
> again, now that I've got rid of the persistent
> PHP connections?
You could, but try to turn off prepared
statements in PDO first.
--
marko
--
Sent via pgsql-general m
DBHOST, DBPORT, DBNAME), DBUSER, DBPASS, $options);
>>
>> and restarted Apache 2.2.3,
>> but that error is still there:
>>
>> SQLSTATE[26000]: Invalid sql
>> statement name: 7 ERROR: prepared
>> statement "pdo_stmt_000a" does not exist
o
> find such values?
CREATE OR REPLACE FUNCTION is_utf8(text)
RETURNS bool AS $$
try:
args[0].decode('utf8')
return True
except UnicodeDecodeError:
return False
$$ LANGUAGE plpythonu STRICT;
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.o
you install package in non-standard location,
you need to set PYTHONPATH in postgres server environment
to point to there, otherwise PL won't see it.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
untry.
pgcrypto does not do signing, sorry.
But you can do it with PL/Python or PL/Perl and their wrapper libraries
around OpenSSL (or any other crypto library).
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
SS1wnzU+wRygZ4CLIV9DGSs9bxBc4r9e71C8s9B5ms6Kpggmc12kdmqVHBRO28bPWb/YLCej59gZFFkvcCudweNAT4qHvVqWsOtFCf9kE4q92UIv1JcwSDU=
>
> This hash has 172 chars
>
> Does someone know where is my problem? Is there other way to implement? or
> is it simply impossible??
These two operations are not equivalent.
--
mark
>>> could become a mechanism for doing what you describe, but I
>>> suspect there would be significant work involved in harnessing
>>> them to that task.
>>
>> Actually I wasn't aware of the concurrency issue of write-able
>> CTE's.
>
> Th
> FROM "Test";
>
> Encryptions works fine, but the decrypting returns "Corrupt data".
> What am I doing wrong?
- if this is the SQL you test with, make sure the table is empty...
- this message may also appear if the passphrase for secret key is wrong.
[this nee
On 10/30/09, Sam Mason wrote:
> On Fri, Oct 30, 2009 at 01:45:24PM +0200, Marko Kreen wrote:
> > On 10/30/09, Tom Lane wrote:
>
> > > That was the point of my '1 day -25 hours' example. Whether you
> > > consider that positive or negative seems mighty
gt; consider that positive or negative seems mighty arbitrary.
If I can add it to a timestamp and get a deterministic result,
then we already have decided how to interpret the arbitrariness.
Might as well be consistent then.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@
On 7/16/09, Rafael Martinez wrote:
> Marko Kreen wrote:
> > On 7/16/09, Rafael Martinez wrote:
> >> Peter Eisentraut wrote:
> >> >
>
> >> > You need to recompile your module.
> >>
> >> We recompile the module automatically wh
ny other ideas?
The version you compile against is not the version you have running.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> Triggers are generally more robust. Quick example:
> NEW.noteid := SELECT 1+ COALESCE( (SELECT noteid FROM "Notes" WHERE
> userkey=NEW.userkey ORDER BY noteid DESC LIMIT 1), 0 );
Can you please write me the whole trigger? I've been reading the manual for
an hour and I have no idea in where to a
ave to make nested queries and where would I do it?
Thank you for help.
Regards,
Marko Pahić
On 6/11/09, Matt Amos wrote:
> On Thu, Jun 11, 2009 at 2:48 PM, Marko Kreen wrote:
> > On 6/11/09, Matt Amos wrote:
> >> On Thu, Jun 11, 2009 at 1:13 PM, Brett Henderson wrote:
> >> >> See pgq.batch_event_sql() function in Skytools [2] for how to
>
t;
> > I'll take a look.
>
> it was looking at the skytools stuff which got me thinking about using
> txids in the first place. someone on the osm-dev list had suggested
> using PgQ, but we weren't keen on the schema changes that would have
> been necessary.
E
On 6/11/09, Brett Henderson wrote:
> Marko Kreen wrote:
>
> > 4-byte xids on btree may create data corruption.
> >
> >
> Can you be more specific on this? I'm aware of xid being an unsigned
> integer which means we need to deal with the cast resulting in nega
event_sql() function in Skytools [2] for how to
query txids between snapshots efficiently and without being affected
by long transactions.
In fact perhaps you can use PgQ directly instead building your own.
It is built quite similarly to what you are planning - periodic
snapshots and then queries on
more uncertain, we have no idea if we have such hooks
from Postgres. Also note there are no plans to get it 2PC with the
local surrounding TX. This seems like overkill...
Anyway - ATM I'm still some time inactive on plproxy front.
If someone wants to take stab on experimenting with such
ling in 8.4.
In older version maybe you can use wrapper function around dblink
that constructs per-user connect string.
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
>
> >
>
> I was thinking about that. But I don't understand, how can I pass the
> list of id's. Should I turn the output of a select into an array? How
> then? What if the array gets hundreds of items long?
Yes, array works fine. And if it's long, then let it
On Jul 31, 1:34 am, [EMAIL PROTECTED] (Tom Lane) wrote:
> marko <[EMAIL PROTECTED]> writes:
> > I'm running FreeBSD 6.2 and I have Postgresql 8.2.4 installed with
> > Perl v5.8.8. I'm trying to test DBD-Pg-2.8.7 after compilation and I
> > get this error after
On Jul 31, 1:34 am, [EMAIL PROTECTED] (Tom Lane) wrote:
> marko <[EMAIL PROTECTED]> writes:
> > I'm running FreeBSD 6.2 and I have Postgresql 8.2.4 installed with
> > Perl v5.8.8. I'm trying to test DBD-Pg-2.8.7 after compilation and I
> > get this error after
I'm running FreeBSD 6.2 and I have Postgresql 8.2.4 installed with
Perl v5.8.8. I'm trying to test DBD-Pg-2.8.7 after compilation and I
get this error after 'make test':
PGINITDB="/usr/local/pgsql/bin/initdb" PERL_DL_NONLAZY=1 /usr/bin/perl
"-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/li
On 3/14/08, Erik Jones <[EMAIL PROTECTED]> wrote:
> On Mar 14, 2008, at 7:17 AM, Marko Kreen wrote:
> > To put it to core Postgres, it needs to be conceptually sane
> > first, without needing ugly workarounds to avoid it bringing
> > whole db down.
> >
On 3/14/08, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 2:18 PM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 3/13/08, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > > An application which uses tsearch2 ('SELECT set_curdict() /
one can never
> be
> sure when session is started. As a countermeasure there is a need to call
> set_curdict() in every transaction (which is very fast), but one needs
> to remember
> to call that set_curdict() every time.
>
> ON CONNECT trigger would solve that neatly!
Hm
> >
> > So that query evaluator can exclude unnecessary partitions.
>
> Ok: that would be another way of having partitions, right?
Yes, effect should be same.
--
marko
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
k on later.
> At least I would like to see it working, since there is nothing in the docs
> that says it shouldn't be working...
> 4) I am not able to rewrite my queries.
Have fun then.
--
marko
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
u are
doing select * from tbl; in remote db, which makes the
exercise quite pointess IMHO.
I obviously would recommend pl/proxy for such task, but that
would expect you are able to write your queries. If you are
in situation where you don't control the queries, then plproxy
q
any countervailing efficiency gain from those extra
> cycles.
AFAIK we have a plan to update string hash in 8.4 to fastest
available (Jenkins lookup3). Maybe we should update integer
hash too then to the best:
http://www.cris.com/~Ttwang/tech/inthash.htm
("32 bit Mix Functions" is t
simple GRANTs
can give you and also give ability to do smooth schema upgrades
without applications noticing.
--
marko
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ou are better off doing proper
sign/verity in client.
Another path would be to look for PLs that have module for
sign+verify - I'd guess that both plpythonu and plperlu
should have those.
--
marko
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
oblem has never been in locking down
the interpreter vX.Y, but locking down interpreter vX.Y+1, when
previously work was done on vX.Y. Without upstream developers
cooperation this has been too painful.
So the interesting thing in the posting is not that he succeeded
locking Python down, but that he i
ctid" of an
> record is the logical "current version" of that record, and used to
> compare with txid returned by "FUNCTIONS-TXID-SNAPSHOT"?
No, it is just physical location of the row.
--
marko
---(end of broadcast)-
rg/projects/skytools
--
marko
---(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
nt lighter, easier to manage, and run faster.
I don't understand you. You basically need only 3 SQL functions
to read events from PgQ:
SELECT * from pgq.next_batch();
SELECT * from pgq.fetch_batch_events();
SELECT * from pgq.finish_batch();
To publish events t
> <http://docs.huihoo.com/api/skytools/pgq-module.html>
>
> In effect, once you start defining more semantics for this, I think it
> rapidly transforms into a message queueing system, and you might as
> well go straight to something full-fledged like pgq...
Sligtly
anks a lot...
This seems to be appropriate task for pl/proxy:
https://developer.skype.com/SkypeGarage/DbProjects/PlProxy
--
marko
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
that part of code to give better error messages.
This is pretty common mistake that can happen.
--
marko
---(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
e not test
keys, then only public key and pgpdump output of private key,
if should not inlude any secret info.
(http://www.mew.org/~kazu/proj/pgpdump/)
I really like to understand whats going on...
--
marko
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
AST (BYTEA AS TEXT) WITHOUT function;
Ah, ok. But why do you need to use the _bytea version?
> The public/private keys should match, as I can encrypt/decrypt the
> message using gpg alone. Inserting the data into a table and using
> pgcrypto functions fail.
(pgp_sym_encrypt()) stuff
seem to be excessive.
So either you have found a bug in pgcrypto which is dependant
on public key algo/OS/CPU/OpenSSL/compiler details or you
have some mistake on your own (eg, your private and public key
does not match).
So I need more details to understand your problem.
--
marko
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
7;d ask here ;-)
Maybe using digest(.., 'md5') function from pgcrypto would be better?
It gives bytea immidiately.
--
marko
---(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
you don't need to store credit card at all, just store
hash and then compare it with the hash of user-inputted one.
For that it's preferable to use crypt() function with crypt-blowfish
hash, which is couple of magnitudes stronger that MD5/SHA* for that
purpose.
> I'd wel
) in the same connection, they will always be
> directed to the SAME MACHINE in its different connections, no balancing
> optimization at all.
To use less connections on server side.
--
marko
---(end of broadcast)---
TIP 9: In versions bel
On 9/7/07, Max Zorloff <[EMAIL PROTECTED]> wrote:
> On Fri, 07 Sep 2007 10:58:36 +0400, Marko Kreen <[EMAIL PROTECTED]> wrote:
> >> The pgpool (I tried 3.1, 3.4 and pgpool-II 1.2) works fine but has the
> >> following problem - after some time it
> >> j
sactions, you could set
query_timeout to some small number (1-3) to see where
errors appear.
Both timeouts are not something I would put into productions
config, so the code should be fixed still...
--
marko
---(end of broadcast)---
TIP 1: if posting
On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Note that it's much better to err on the smaller values.
>
> > Extra index pass is really no problem.
>
> I beg to differ ...
Well, if Postgres trie
n the smaller values.
Extra index pass is really no problem. VACUUM getting
"Out of memory" may not sound like a big problem, but the scary
thing is - the last VACUUM's memory request may succeed and that
means following queries start failing and that is big problem.
--
marko
--
reason turned out to be
combination of overcommit=off, big maint_mem and several parallel
vacuums for fast-changing tables. Seems like VACUUM allocates
full maint_mem before start, whatever the actual size of the table.
Fix was to put "set maint_mem=32M" before small vacuums and
serialize
cation in general. Asyncronous replication
will break down too.
--
marko
---(end of broadcast)---
TIP 6: explain analyze is your friend
rypto or in application.
Thus you can have only public-key in public database,
credit-card numbers are encrypted with it, later actual
billing happens in separate, highly secured system that
has corresponding private key available to decrypt the data.
--
marko
---(end of b
it for each salt. Which basically gives the effect that
each hash needs to be attacked separately.
In case of attacking one hash the salt does not matter,
only the algorithm counts then. In that case as i said,
event salted md5 is weaker than des-crypt.
--
marko
---(end of
On 6/5/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
both md5 and sha1 are actually easier to bruteforce than
the old DES-based crypt.
If this statement seems weird - the problem is the speed.
MD5 and SHA1 are just faster algorithms than des-crypt.
And there's nothing wrong with f
On 6/5/07, Brian Mathis <[EMAIL PROTECTED]> wrote:
On 6/5/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
> Both md5 and sha1 are bad for passwords, no salt and easy to
> bruteforce - due to the tiny amount of data in passwords.
>
> Proper ways is to use crypt() function fro
eforce - due to the tiny amount of data in passwords.
Proper ways is to use crypt() function from pgcrypto module.
Due to historical accident is has bad name which hints at
encryption, actually its only purpose is to hash passwords.
Read more in pgcrypto doc.
--
marko
---(end
Hi,
is there a system table in which postgres stores all data about newly
created database?
together with database objects, tables, columns, functions etc.
thanks
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
htt
Hi,
i'm trying to make update on multiple tables but don't know how.
is something like this posible with postgresql?
update table1
join table2 on (table1.id=table2.t1)
join table3 on (table2.id=table3.t2)
set table1.name='test', table2.sum=table1.x+table2.y,
table3.cell='123456789'
where table
more easily referred as SHA2.
SHA-1 is really a fix of the original SHA (sometimes referred to as SHA-0).
--
marko
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On 5/9/06, Joe Kramer <[EMAIL PROTECTED]> wrote:
On 5/9/06, Marko Kreen <[EMAIL PROTECTED]> wrote:
> The fact that Fedora pgcrypto is linked with OpenSSL that does not
> support SHA256 is not a bug, just a fact.
It's not Fedora only, same problem with Gentoo/portage.
I
nicest solution to your problem would be self-compiled
pgcrypto, that would work with stock PostgreSQL. As the conflict
happens with only (new) SHA2 functions, I can prepare a patch for
symbol conflict, would that be satisfactory for you?
--
marko
---(end of broadcast)--
You need to recompile PostgreSQL. Don't try to use non-OpenSSL
pgcrypto with OpenSSL PostgreSQL, it will crash due to symbol
conflict.
Another variant is to try to compile separate OpenSSL 0.9.8 and
compile PostgreSQL against that. So you don't need to upgrade
syst
On 4/3/06, Kai Hessing <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
> > Just a shot in the dark: does the plan stay the same,
> > when you remove the ' AND status > -1' ?
>
> No difference: I skipped the 'AND status > -1' and have the fol
s=1)
Just a shot in the dark: does the plan stay the same,
when you remove the ' AND status > -1' ?
--
marko
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if y
uld be if i could simply insert untoasted
values there, so i can put some fake values there and detect them
later. (As I cannot query 'what table row has toast_oid')
--
marko
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On 2/14/06, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Zend isn't, last time I looked (which, granted, was ages ago), needed
> to run PHP, but it may be now.
I guess you are thinking about "Zend - PHP Optimizer" not "Zend - PHP Core".
--
marko
---
html#SQL-SYNTAX-IDENTIFIERS
--
marko
---(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
lls
- you need to bump epoch if you reload dump.
otherwise seems to work fine.
Btw it uses TopTransactionId, so subtransactions should not be problem.
--
marko
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ding
> this to Postgres.
Well, starting from 8.1, contrib/pgcrypto does public-private key
encryption, including password-protected private keys (OpenPGP).
No keygen though, so you need to create keys externally.
You could build something on it.
--
marko
---(end of br
solution - no secret key is needed for
regular operation. It is only needed for restore operation.
--
marko
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On 12/23/05, Carlos Moreno <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
>
> >On 12/22/05, Carlos Moreno <[EMAIL PROTECTED]> wrote:
> >
> >>The problem is, when I execute the SQL statement:
> >>
> >>create or replace function sha1
to compile pgcrypto
against OpenSSL 0.9.8. Or upgrade to PostgreSQL 8.1,
where they are included.
Ofcourse, that is no fun.
If you want to hack, you could try adding SHA224 to the SHA2
implementation in 8.1. There are currently only SHA256/384/512
hashes implemented. (AFAIR it
On Mon, Dec 12, 2005 at 09:36:27PM -0600, Jim C. Nasby wrote:
> On Mon, Dec 12, 2005 at 02:38:57PM +0200, Marko Kreen wrote:
> >
> > I needed to re-set all permissions on a database as the database
> > access philosophy changed. But as it had a lot of tables, I was
> >
in]
tables = main_table, # generates grant for main_table_nr_seq
test_table! # no grant will be generated
--
marko
#! /usr/bin/env python
"""Generator for PostgreSQL permissions.
ConfigParser docs: http://docs.python.org/lib/module-ConfigParser.html
ut the usual would be '8.1'...
--
marko
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
1 - 100 of 120 matches
Mail list logo
