2008/5/9 tekwiz <[EMAIL PROTECTED]>:
> How do I code PL/pgSQL to select a procedure name from a table and
> then execute it from within another procedure and pass that procedure
> a particular ROWTYPE and return a ROWTYPE?
you can use EXECUTE statement. But you have to be careful when these
functi
Craig Vosburgh <[EMAIL PROTECTED]> writes:
> We've dumped the locks and it shows that all locks have been granted so
> it appears that it is not a lock that is standing in our way. We've
> also gone in via psql while the update is hung and were able to perform
> an update on the offending table wi
How do I code PL/pgSQL to select a procedure name from a table and
then execute it from within another procedure and pass that procedure
a particular ROWTYPE and return a ROWTYPE?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://ww
All,
I'm hoping for some help on trying to figure out what is going on with
our postgres implementation. We have an application that uses Hibernate
to persist objects into a Postgres database. We've run into a
semi-repeatable problem (every other or every third test run) where we
issue an update
On Fri, 09 May 2008 17:18:31 -0300
Martin Marques <[EMAIL PROTECTED]> wrote:
> I'm doing some tests with Slony-I on 2 PG 8.3 servers (Debian
> testing) and I stumbled with some issues related to the Slony docs
> (from the slony.info page).
This really belongs on the slony lists:
http://lists.slo
I'm doing some tests with Slony-I on 2 PG 8.3 servers (Debian testing)
and I stumbled with some issues related to the Slony docs (from the
slony.info page).
For example, I configured /etc/slony1/prueba/slon.conf and
/etc/slony1/slon_tools.conf correctly to replicate three tables I have
in the
Hello,
I got a problem to restore a database, because there is a problem in my
production database, which not suppose to happen like that, but it happen, not
sure is a postgres bug or not.
I got a table call CS_SR_MTHLY_RTN which has MTHLY_RTN_ID (INTEGER) as a
primary key. So the MTHLY_RTN_ID v
Hello,
I got a problem to restore a database, because there is a problem in my
production database, which not suppose to happen like that, but it happen, not
sure is a postgres bug or not.
I got a table call CS_SR_MTHLY_RTN which has MTHLY_RTN_ID (INTEGER) as a
primary key. So the MTHLY_RTN_ID v
<[EMAIL PROTECTED]> writes:
> PANIK: ERROR_STACK_SIZE exceeded
> the rest of the message is unfortunately in german then i have to
> restart the postgres-service manually this error is very easy
> reproducible at my environment
What this typically means is that you've got an encoding/locale
confi
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> There is nothing wrong with storing int4 epoch in your tables to save a
> little space if that suits your application.
... Just make sure you're safely away from the scene of the crime
before 2038 ...
regards, tom lane
--
Se
William Temperley wrote:
> On Thu, May 8, 2008 at 6:14 PM, Magnus Hagander <[EMAIL PROTECTED]>
> wrote:
> > William Temperley wrote:
> >> > >
> >> > > Any ideas why this might be happening, and how I can stop it?
> >> >
> >> > It'd be interesting to know what the stats collector is actually
> >>
On Fri, May 9, 2008 at 8:55 AM, Fernando Schapachnik
<[EMAIL PROTECTED]> wrote:
> En un mensaje anterior, Merlin Moncure escribió:
>> On Thu, May 8, 2008 at 7:52 AM, Fernando Schapachnik
>> <[EMAIL PROTECTED]> wrote:
>> > Pg 8.1.11, I try to change sequences as default value of a table, then
>> > r
En un mensaje anterior, Merlin Moncure escribió:
> On Thu, May 8, 2008 at 7:52 AM, Fernando Schapachnik
> <[EMAIL PROTECTED]> wrote:
> > Pg 8.1.11, I try to change sequences as default value of a table, then
> > remove old sequence:
> >
> > # \d table1
> > Table "table
On Fri, May 9, 2008 at 3:15 AM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Thu, May 8, 2008 at 10:00 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>>
>> Our timestamp has a much larger range than a 4-byte time_t, docs say:
>>
>> 4713 BC
>> 294276 AD
>
> Which is normally great.
On Thu, May 8, 2008 at 7:52 AM, Fernando Schapachnik
<[EMAIL PROTECTED]> wrote:
> Pg 8.1.11, I try to change sequences as default value of a table, then
> remove old sequence:
>
> # \d table1
> Table "table1"
> Column | Type | Modifiers
>
Pg 8.1.11, I try to change sequences as default value of a table, then
remove old sequence:
# \d table1
Table "table1"
Column | Type | Modifiers
+-+---
id
No problems here.
create table regions (id integer, name varchar);
alter table regions alter column name set default 'bavaria';
PostgreSQL 8.3.1 vc++ build 1400 xp sp2
# - Memory -
shared_buffers = 32MB# min 128kB or max_connections*16kB
# (change requires rest
On Fri, May 09, 2008 at 04:59:30AM -0400, Justin wrote:
> generail this don't hurt us but we have some needs with data coming from
> manufacturing testing applications that needs to keep the timestamps to
> .000,000,001 aka 1 nano second.
> what would be the easiest way to do this?
I would sug
We noticed that several records which have a time stamp column have
the same time stamp which i can understand given the time stamps have 1
microsecond resolution.
generail this don't hurt us but we have some needs with data coming from
manufacturing testing applications that needs to keep t
hi all,
first i create a table
create table regions (id integer, name varchar);
then i want to set a default value for a column, e.g.
alter table regions alter column name set default 'bavaria';
at this point crashes the database with the message
PANIK: ERROR_STACK_SIZE exceeded
the rest of
On Thursday 8 May 2008 Tom Lane's cat, walking on the keyboard, wrote:
> Maybe the original strings had more than one instance of 'TIF'?
Opsyou're right, I've checked with a backup copy and I found four records
with the double tif pattern.
I should have get it beforesorry!
Luca
--
Sent
On Thu, May 8, 2008 at 12:10 PM, John Gateley <[EMAIL PROTECTED]> wrote:
>
> On Thu, 8 May 2008 10:58:47 -0700
> Alan Hodgson <[EMAIL PROTECTED]> wrote:
>
> > On Thursday 08 May 2008, John Gateley <[EMAIL PROTECTED]> wrote:
> > > But the new database, mydbtest, always has slow queries.
> > > I
On Thu, May 8, 2008 at 10:00 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Our timestamp has a much larger range than a 4-byte time_t, docs say:
>
> 4713 BC
> 294276 AD
Which is normally great. Doesn't it have greater precision in the
modern era or something like that?
If you
23 matches
Mail list logo
