On Wed, Jul 13, 2005 at 03:53:26PM -0500, [EMAIL PROTECTED] wrote:
I think a better approach is to handle configuration management with a
table in each schema. Update the schema, update the table.
We already do that anyways. Our schema scripts have their
CVS version tag embedded in an INSERT
I've been going through some old backups, and found databases from
pgsql versions as old as 7.0 (7.0, 7.1, 7.3, and 7.4 to be precise).
I'm trying to build these older versions specifically so I can dump
the data and see what I want to keep and what I can erase.
7.3 and 7.4 appear to have
On Wed, Jul 13, 2005 at 05:23:06PM -0500, Jeffrey Melloy wrote:
I'm currently looking at implementing a system almost exactly like this,
and I was wondering if there is anything around that does this.
Attached find how GNUmed does it based on recent discussion
here on the list.
Karsten
--
Ron Mayer wrote:
Martijn van Oosterhout wrote:
Well, you get another issue, alignment. If you squeeze your string
down, the next field, if it is an int or string, will get padded to a
multiple of 4 negating most of the gains. Like in C structures, there
is padding to optimise access.
What is the best way to quickly and reliably stop postgres? We've found
that pg_ctl doesn't work for us very well, frequently failing to
actually stop the postmaster (it times out and reports that it has
failed to stop). This is the same even if we use -m immediate.
We don't want to kill -9,
Tom Lane wrote:
Bob [EMAIL PROTECTED] writes:
Doesn't that really only save you from having someone come in at the OS
level and copying your data files and than moutning them on a differet
server/database. A person could still come in to psql as a dba or anyone
for
that matter with
I have a production database where we just encountered the following error:ERROR: could not open relation 1663/32019395/94144936: No such file or directory Here's the output of SELECT version():PostgreSQL 8.0.3 on i686-pc-linux-gnu, compiled by GCC 2.95.4Here's uname -a:Linux hostname 2.6.11.8 #8
On Wed, Jul 13, 2005 at 01:28:45PM -0500, Jason Tesser wrote:
I have the following store dproc but when I run it I am getting the
error
ERROR: invalid input syntax for integer: (1)
CONTEXT: PL/pgSQL function irispermissionget line 9 at return next
What am I doing wrong?
The function
Karsten Hilbert wrote:
My main concern, however, was whether the *approach* is
sound, eg using a separate database name per release or IOW
version. One way would be to use the database name gnumed
regardless of release, another way would be to use
gnumedX_Y for release X.Y. I wonder whether the
Joshua D. Drake wrote:
If you are using savepoints you can rollback to a specific point of
a parent transaction.
Although you can't use savepoints (explicitly) in functions. PL/PgSQL
exceptions (which are actually implemented internally via savepoints)
can be used to achieve a similar
I'm developing a habit of being the most frequent replier to my own posts, but anyway: I discovered the meaning of 1663, which is the default tablespace oid.But I still need help with diagnosis and treatment... -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open
On Wed, Jul 13, 2005 at 04:29:41PM -0700, Gregory Youngblood wrote:
It gets through most of the make process, but then at the point where
it starts creating files like GNUmakefile, it returns:
sed: file conftest.sl line 35: unterminated `s' command
The problem is that GCC now gives a
Here is the link in case your fingers are broken and it hurts to type;)
http://www.postgresql.org/docs/8.0/interactive/encryption-options.html
On 7/13/05, Matt McNeil [EMAIL PROTECTED] wrote:
Greetings,
I need to securely store lots of sensitive contact
information andnotes in a freely
Harry Mantheakis wrote:
Correct. The lesson is, never use locale support for Asian languages
and multibyte encodings including UTF-8.
Thank you for your reply - much appreciated.
I'm now concerned if and how this will affect ORDER BY query results (and
other functions) with respect to
Thanks for the tips. It kind of worked. I got passed that point, but
then got to another set of errors.
I'm going to change my approach. I'm trying to locate some older
Linux ISOs that I can install in a vmware virtual environment and try
to build in there. Since all I want is to dump my
Alvaro Herrera wrote:
I don't think you can use just plpgsql's parser. The problem is that it
relies on the main backend parser to figure out anything it doesn't
understand.
I think it depends on what kind of information you want to extract from
a PL/PgSQL function definition. The PL/PgSQL
Vivek Khera wrote:
The first sentence rules out MySQL, so the second sentence should read
So that leaves Postgres. Your problem is solved ;-)
(If you are accustomed to Oracle, you are probably expecting an ACID
database, which rules out MySQL too).
Does MySQL with InnoDB not qualify as
On Thu, Jul 14, 2005 at 02:46:01PM +1000, Neil Conway wrote:
Vivek Khera wrote:
The first sentence rules out MySQL, so the second sentence should read
So that leaves Postgres. Your problem is solved ;-)
(If you are accustomed to Oracle, you are probably expecting an ACID
database,
Harry Mantheakis wrote:
Correct. The lesson is, never use locale support for Asian languages
and multibyte encodings including UTF-8.
Thank you for your reply - much appreciated.
I'm now concerned if and how this will affect ORDER BY query results (and
other functions) with
101 - 119 of 119 matches
Mail list logo
