Scott Marlowe writes:
> On Wed, Sep 20, 2017 at 12:14 PM, Jerry Sievers
> wrote:
>
>> Basically as per $subject.
>>
>> We took a perf hit moving up to newer hardware and OS version which
>> might in some cases be OK but admittedly there is some risk running a
>> much older app (Pg 9.3) on a ker
On Wed, Sep 20, 2017 at 12:14 PM, Jerry Sievers wrote:
> Basically as per $subject.
>
> We took a perf hit moving up to newer hardware and OS version which
> might in some cases be OK but admittedly there is some risk running a
> much older app (Pg 9.3) on a kernel/OS version that nowhere near exi
On Wed, Sep 20, 2017 at 01:14:14PM -0500, Jerry Sievers wrote:
> Be curious to hear of issues encountered and particular to eager to know
> if disabling any kernel 4.x features helped.
What was the old kernel/OS ? wheezy / kernel 3.x ?
Perhaps try these ideas ?
https://www.postgresql.org/message
Basically as per $subject.
We took a perf hit moving up to newer hardware and OS version which
might in some cases be OK but admittedly there is some risk running a
much older app (Pg 9.3) on a kernel/OS version that nowhere near existed
when 9.3 was current.
Be curious to hear of issues encounte
On Tue, Aug 8, 2017 at 6:25 PM, Melvin Davidson
wrote:
>
> *Have you looked at the TUPLES ONLY option?*
>
> *-t* *--tuples-only*
>
> *Turn off printing of column names and result row count footers, etc. This
> is equivalent to the \t command.*
> *https://www.postgresql.org/docs/9.4/static/app-p
On Tue, Aug 8, 2017 at 9:16 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Hey all, looking for thoughts on a feature request:
>
> I run quite a few queries, using psql, that are intended for exceptional
> situations. When there are no results, which is expected, I still get the
> t
Hey all, looking for thoughts on a feature request:
I run quite a few queries, using psql, that are intended for exceptional
situations. When there are no results, which is expected, I still get the
table header and basic frame showing up in the output. The option I'd like
is to be able to suppr
>
> Feature freeze is in effect and we have a Beta release out. Major bugs or
> major usability issues are the only things that would cause any change to
> the catalogs at this point and there likely won't be many, if any, of those
> (at least not ones that necessitate catalog changes - must disco
On Wed, May 24, 2017 at 9:22 AM, Neil Anderson
wrote:
> Hi all,
>
> I am writing a blog post about changes to the catalogs between v9.6.3
> and the upcoming v10. I've diffed the catalogs.sgml and it looks
> pretty informative so far, see
> https://gist.github.com/sql-migrate/8e87214cc3127ba52fc93
Hi all,
I am writing a blog post about changes to the catalogs between v9.6.3
and the upcoming v10. I've diffed the catalogs.sgml and it looks
pretty informative so far, see
https://gist.github.com/sql-migrate/8e87214cc3127ba52fc93a589f040425.
I'm not too familiar with the release cycle and wheth
Hi all
This DbUnit extension for PHPUnit is driving me insane. On my
deathbed, the days of my life I have wasted debugging this testing
framework will haunt me.
Basic things like serial IDs fields, boolean values and timestamps
seem to require omission or unholy workarounds in order to get tests
What exactly are the features you are looking for? Materialized views are
treated as tables in PostgreSQL and you can create indexes on them.
https://www.postgresql.org/docs/9.4/static/sql-creatematerializedview.html
"CREATE MATERIALIZED VIEW is *similar to **CREATE TABLE* AS, except that it
also
Is there any work being done on materialized views for version 9.7? This
postgresql feature is severely lacking compared to similar features like
indexed views by sql server.
Jehan-Guillaume de Rorthais wrote:
> > Yeah. I recall there being some stupid limitation in ALTER TABLE .. ADD
> > CONSTRAINT USING INDEX to create a primary key from a previously
> > existing unique index, which would be very good to fix (I don't recall
> > what it was, but it was something infu
On Mon, 29 Aug 2016 13:13:17 -0300
Alvaro Herrera wrote:
> Jehan-Guillaume de Rorthais wrote:
> > On Mon, 29 Aug 2016 13:38:03 +0200
> > hubert depesz lubaczewski wrote:
> >
> > > Hi,
> > > we have rather uncommon case - DB with ~ 50GB of data, but this is
> > > spread across ~ 8 tables.
>
On Mon, Aug 29, 2016 at 01:13:17PM -0300, Alvaro Herrera wrote:
> > > This happens on Pg 9.5. Are there any plans to make getting schema
> > > faster for such cases? Either by parallelization, or at least by getting
> > > schema for all tables "at once", and having pg_dump "sort it out",
> > > inst
Jehan-Guillaume de Rorthais wrote:
> On Mon, 29 Aug 2016 13:38:03 +0200
> hubert depesz lubaczewski wrote:
>
> > Hi,
> > we have rather uncommon case - DB with ~ 50GB of data, but this is
> > spread across ~ 8 tables.
> >
> > Running pg_dump -Fd -jxx dumps in parallel, but only data, and MOS
On Mon, 29 Aug 2016 13:38:03 +0200
hubert depesz lubaczewski wrote:
> Hi,
> we have rather uncommon case - DB with ~ 50GB of data, but this is
> spread across ~ 8 tables.
>
> Running pg_dump -Fd -jxx dumps in parallel, but only data, and MOST of
> the time is spent on queries that run sequen
Hi,
we have rather uncommon case - DB with ~ 50GB of data, but this is
spread across ~ 8 tables.
Running pg_dump -Fd -jxx dumps in parallel, but only data, and MOST of
the time is spent on queries that run sequentially, and as far as I can
tell, get schema of tables, and sequence values.
This
On 08/16/2016 01:15 PM, Jim Nasby wrote:
On 8/16/16 1:05 PM, Adrian Klaver wrote:
On 08/16/2016 07:54 AM, Jim Nasby wrote:
On 8/14/16 5:13 AM, Xtra Coder wrote:
- ability to switch session language from 'sql' to 'pl/pgsql'
Actually, something I wish I had was the ability to temporarily switc
On 08/16/2016 01:15 PM, Jim Nasby wrote:
On 8/16/16 1:05 PM, Adrian Klaver wrote:
On 08/16/2016 07:54 AM, Jim Nasby wrote:
On 8/14/16 5:13 AM, Xtra Coder wrote:
- ability to switch session language from 'sql' to 'pl/pgsql'
Actually, something I wish I had was the ability to temporarily switc
On 8/16/16 1:05 PM, Adrian Klaver wrote:
On 08/16/2016 07:54 AM, Jim Nasby wrote:
On 8/14/16 5:13 AM, Xtra Coder wrote:
- ability to switch session language from 'sql' to 'pl/pgsql'
Actually, something I wish I had was the ability to temporarily switch
to an entirely different interpreter (su
2016-08-16 21:50 GMT+02:00 Jim Nasby :
> On 8/16/16 11:17 AM, Chris Travers wrote:
>
>> I am thinking adding a temporary keyword to functions would make a lot
>> more sense.
>>
>
> Well, right now that's just syntactic sugar, so I think the only real
> benefit might be visibility (though, really w
On 8/16/16 11:17 AM, Chris Travers wrote:
I am thinking adding a temporary keyword to functions would make a lot
more sense.
Well, right now that's just syntactic sugar, so I think the only real
benefit might be visibility (though, really we should be marketing the
idea that you can create al
On 08/16/2016 07:54 AM, Jim Nasby wrote:
On 8/14/16 5:13 AM, Xtra Coder wrote:
- ability to switch session language from 'sql' to 'pl/pgsql'
Actually, something I wish I had was the ability to temporarily switch
to an entirely different interpreter (such as ipython), while still
retaining curr
On Tue, Aug 16, 2016 at 3:11 PM, Merlin Moncure wrote:
> On Sun, Aug 14, 2016 at 5:58 AM, Chris Travers
> wrote:
>
> >>
> >> All this seems to be a huge change which will definitely not appear any
> >> time soon.
> >
> > I am willing to bet that DO $$ $$; blocks are neither planned nor
> > param
On 8/14/16 5:13 AM, Xtra Coder wrote:
- ability to switch session language from 'sql' to 'pl/pgsql'
Actually, something I wish I had was the ability to temporarily switch
to an entirely different interpreter (such as ipython), while still
retaining current database connection and context. Tha
On Sun, Aug 14, 2016 at 5:58 AM, Chris Travers wrote:
>
> On Sun, Aug 14, 2016 at 12:13 PM, Xtra Coder wrote:
>>
>> Thanks, I'm aware about ability to create temp functions, but this is
>> actually too much overhead - I mean unneeded boilerplate code, but it seems
>> in current state it is "the l
On Sun, Aug 14, 2016 at 12:13 PM, Xtra Coder wrote:
> Thanks, I'm aware about ability to create temp functions, but this is
> actually too much overhead - I mean unneeded boilerplate code, but it seems
> in current state it is "the least evil" which I have to use.
>
> I think 'what i need' is sup
Thanks, I'm aware about ability to create temp functions, but this is
actually too much overhead - I mean unneeded boilerplate code, but it seems
in current state it is "the least evil" which I have to use.
I think 'what i need' is support for following
- ability to switch session language from 's
If all you want is a temporary function, you *can* create it in the pg_temp
namespace though that seems hackish.
Maybe a better solution would be to extend CREATE FUNCTION in a way that
allows you to CREATE TEMPORARY FUNCTION?
On Sun, Aug 14, 2016 at 9:28 AM, Xtra Coder wrote:
> Thanks for the
Thanks for the link. After looking through it i see following major points:
- thread is from 2013 and nothing changed today in 2016
- quote from that thread (C) Dimitri Fontaine
"That topic apparently raises each year and rehash the same points"
(So ... there should be more similar discussio
On Fri, Aug 12, 2016 at 11:34 PM, Xtra Coder wrote:
...
> In my particular case I'm more interested in an easy way to create complex
> SELECTs that require usage of variables in the one-time through-away scripts
> (some-time during experiments for implementation of functions, to see
> immediate re
Xtra Coder wrote:
> May you have the link to 'DO'-discussion to take a look on it? I was trying
> to google for something like that, but word 'DO' is too generic to bring
> useful results :(
Probably this is one:
https://www.postgresql.org/message-id/51b624c6@2ndquadrant.com
--
Álvaro Herrer
May you have the link to 'DO'-discussion to take a look on it? I was trying
to google for something like that, but word 'DO' is too generic to bring
useful results :(
In my particular case I'm more interested in an easy way to create complex
SELECTs that require usage of variables in the one-time
On Mon, Aug 8, 2016 at 7:25 PM, Xtra Coder wrote:
> Hi,
>
> I'm just curious about the reasons of the design of 'DO' statement so that
> it is not able to return result of the SELECT in its body.
>
> References:
> https://www.postgresql.org/docs/current/static/sql-do.html
>
> http://stackoverf
On 8/8/16 7:25 PM, Xtra Coder wrote:
With some former experience with MsSQL server, where 'complex' script is
executed easily and straightforward without any 'wrapping', like this
dummy-one ...
DECLARE @a int;
DECLARE @b int;
...
select @a + @b as "a+b"
... every time I need to
Hi,
I'm just curious about the reasons of the design of 'DO' statement so that
it is not able to return result of the SELECT in its body.
References:
https://www.postgresql.org/docs/current/static/sql-do.html
http://stackoverflow.com/questions/14652477/how-to-perform-a-select-query-in-a-do-b
On Mon, May 16, 2016 at 4:08 PM, Adrian Klaver
wrote:
> On 05/16/2016 12:41 PM, David G. Johnston wrote:
>
>> I have a psql script that obtains data via the \copy command and loads
>> it into a temporary table. Additional work is performed possibly
>> generating additional temporary tables but n
On 05/16/2016 12:41 PM, David G. Johnston wrote:
I have a psql script that obtains data via the \copy command and loads
it into a temporary table. Additional work is performed possibly
generating additional temporary tables but never any "real" tables.
Then the script outputs, either to stdout o
On Mon, May 16, 2016 at 3:56 PM, Alan Hodgson
wrote:
> On Monday, May 16, 2016 03:41:23 PM David G. Johnston wrote:
> > I have a psql script that obtains data via the \copy command and loads it
> > into a temporary table. Additional work is performed possibly generating
> > additional temporary
On Monday, May 16, 2016 03:41:23 PM David G. Johnston wrote:
> I have a psql script that obtains data via the \copy command and loads it
> into a temporary table. Additional work is performed possibly generating
> additional temporary tables but never any "real" tables. Then the script
> outputs,
I have a psql script that obtains data via the \copy command and loads it
into a temporary table. Additional work is performed possibly generating
additional temporary tables but never any "real" tables. Then the script
outputs, either to stdout or via \copy, the results.
Does it matter whether
On Thu, Jan 7, 2016 at 2:32 PM, Gavin Flower
wrote:
> On 08/01/16 10:25, David G. Johnston wrote:
>
>> Basically I want to write this:
>>
>> psql -c "SELECT E'\e[1;33m Some Text Here \e[0m';"
>>
>> And have just the text "Some Text Here" colored while everything else is
>> default white.
>>
>> Th
On 08/01/16 10:25, David G. Johnston wrote:
Basically I want to write this:
psql -c "SELECT E'\e[1;33m Some Text Here \e[0m';"
And have just the text "Some Text Here" colored while everything else
is default white.
The \e constructs are the ANSI color escapes which work when using echo -e
I
Basically I want to write this:
psql -c "SELECT E'\e[1;33m Some Text Here \e[0m';"
And have just the text "Some Text Here" colored while everything else is
default white.
The \e constructs are the ANSI color escapes which work when using echo -e
I am using bash 4.2.25(1) on Ubuntu 14.04
Is thi
On Sat, Sep 5, 2015 at 8:36 AM, Marc Mamin wrote:
>
>array_not_nulls(array_agg(case when type='A' then link end ))as ar_a,
>array_not_nulls(array_agg(case when type='B' then link end ))as ar_b,
>array_not_nulls(array_agg(case when type NOT IN ('A', 'B') then link
> end)) as ar_others
>?Formatted query attached in addition to placing it inline. The commentary is
>inline with the query. Basically I've already solved this problem but was
>wondering if someone has a different perspective; or simply observations.
>
>TIA,
>
>David J.
>
>/*
>For a given id there are multiple linke
Formatted query attached in addition to placing it inline. The commentary
is inline with the query. Basically I've already solved this problem but
was wondering if someone has a different perspective; or simply
observations.
TIA,
David J.
/*
For a given id there are multiple linked values of
If you use Amazon Linux on EC2, we have packaged SchemaSpy support for
it. More details are here,
https://lambda-linux.io/blog/2015/05/07/announcing-schemaspy-support-for-amazon-linux/
Best,
Rajiv
On Thu, Jan 16, 2014 at 7:46 PM, Merlin Moncure
wrote:
> On Thu, Jan 16, 2014 at 10:45 AM, Susan C
On Sun, 18 Jan 2015 20:25:48 +0100
Thomas Kellerer wrote:
> Bjørn T Johansen wrote on 18.01.2015 20:20:
> > Just noticed that a column field of type bigint containing a null, becomes
> > a 0 when retrieving it from the resultset using JDBC.
> > If I run the same application against my old 9.3 da
On Sun, 18 Jan 2015 20:20:35 +0100
Bjørn T Johansen wrote:
> Just noticed that a column field of type bigint containing a null, becomes a
> 0 when retrieving it from the resultset using JDBC.
> If I run the same application against my old 9.3 database, the value
> retrieved is a null
>
>
Bjørn T Johansen wrote on 18.01.2015 20:20:
Just noticed that a column field of type bigint containing a null, becomes a 0
when retrieving it from the resultset using JDBC.
If I run the same application against my old 9.3 database, the value retrieved
is a null
You need to show us some
Just noticed that a column field of type bigint containing a null, becomes a 0
when retrieving it from the resultset using JDBC.
If I run the same application against my old 9.3 database, the value retrieved
is a null
Regards,
BTJ
--
--
)
Sent: Wednesday, October 15, 2014 10:19 PM
To: 'Tom Lane'; pgsql-...@postgresql.org; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Any postgres API available to get errorcode for
PQerrorMessage
Thanks Tom,
But that's not what I am looking for.
I need the 'integer'
Appreciate any replies on this.
/rK
-Original Message-
From: Roopeshakumar Narayansa Shalgar (rshalgar)
Sent: Wednesday, October 15, 2014 10:19 PM
To: 'Tom Lane'; pgsql-...@postgresql.org; pgsql-general@postgresql.org
Subject: RE: [GENERAL] Any postgres API available to get
bpq.so.5.3 libpq.so.5
How to resolve by postgresql.spec file?
Regards,
Yogesh
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Rob Sargent
Sent: Wednesday, October 15, 2014 10:08 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Any pos
On 10/15/2014 9:48 AM, Roopeshakumar Narayansa Shalgar (rshalgar) wrote:
I need the 'integer' errorcode
SQLSTATE Error codes are NOT integers, they are strings. note there's
stuff in there like 0100C, 01P01, etc.
--
john r pierce 37N 122W
somewhere on t
: Roopeshakumar Narayansa Shalgar (rshalgar)
Cc: pgsql-...@postgresql.org; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Any postgres API available to get errorcode for
PQerrorMessage
"Roopeshakumar Narayansa Shalgar (rshalgar)" writes:
> HI,
> PQerrorMessage pirints the e
On 10/15/2014 02:17 AM, Roopeshakumar Narayansa Shalgar (rshalgar) wrote:
HI,
PQerrorMessage pirints the error message like (no space
available,etc). Does postgres provide
any API which gives the error code listed in the below appendix;
http://www.postgresql.org/docs/9.1/static/errcodes-ap
"Roopeshakumar Narayansa Shalgar (rshalgar)" writes:
> HI,
> PQerrorMessage pirints the error message like (no space available,etc). Does
> postgres provide
> any API which gives the error code listed in the below appendix;
> http://www.postgresql.org/docs/9.1/static/errcodes-appendix.html
Use
HI,
PQerrorMessage pirints the error message like (no space available,etc). Does
postgres provide
any API which gives the error code listed in the below appendix;
http://www.postgresql.org/docs/9.1/static/errcodes-appendix.html
I need the exact error code so that I can shutdown my application
I do have a development machine using constrained SSD disk, and I would
like to take advantage of compression.
But would not want to reformat everything on ZFS (I'm actually using Ext4).
Nevertheless, seems that Joe had a bad experience with Btrfs (my
expectation was to just migrate from Ext4 t
On 09/13/2014 11:14 AM, Joe Conway wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2014 08:24 AM, Edson Carlos Ericksson Richter wrote:
Any experiences running PostgreSQL 9.3.5 on compressed Btrfs on
Linux?
Yes. It ran great for over a month but once we had some serious data i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2014 08:24 AM, Edson Carlos Ericksson Richter wrote:
> Any experiences running PostgreSQL 9.3.5 on compressed Btrfs on
> Linux?
No personal experience, but someone recently pointed out this article
to me:
"Btrfs considered … helpful"
http:/
Any experiences running PostgreSQL 9.3.5 on compressed Btrfs on Linux?
Thanks,
Edson
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
http://meta.stackoverflow.com/questions/270574/an-experiment-stack-overflow-tv?cb=1
On 5/6/2014 1:22 PM, David G Johnston wrote:
I know that I can pre-process the input file and simply add the needed data
but I am curious if maybe there is some trick to having defaults populate
for missing columns WITHOUT explicitly specifying each and every column that
is present?
if you didn
On Tue, May 05/06/14, 2014 at 01:22:20PM -0700, David G Johnston wrote:
> So, I am trying to import a file into a table and want to assign a sequence
> value to each record as it is imported.
>
> I know that I can pre-process the input file and simply add the needed data
> but I am curious if maybe
So, I am trying to import a file into a table and want to assign a sequence
value to each record as it is imported.
I know that I can pre-process the input file and simply add the needed data
but I am curious if maybe there is some trick to having defaults populate
for missing columns WITHOUT expl
Regards,
Kumar Rajeev Rastogi
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Susan Cassidy
Sent: 17 April 2014 05:36
To: Steven Schlansker
Cc: Tom Lane; pgsql-general@postgresql.org
Subject: Re: [GENERAL] any way for a transaction to "see&quo
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bosco Rama wrote:
> Is it returning the right id? I seem to remember a recent thread
> about Perl DBI returning the wrong id's for certain operations.
Er...can you point me to that thread, please? I'd be very interested
in such a bug.
- --
There aren't multiple connections. It is a CGI program. One connection is
made when the program starts, and that is all.
I've looked at the log. It shows just what I expect, except that the
lookup does not work. 0 rows are returned from the select of the newly
inserted id.
Susan
On Wed, A
No. One gets done automatically when the transaction fails, however. I
can see it in the log.
Susan
On Wed, Apr 16, 2014 at 6:26 PM, Andy Colson wrote:
> On 04/16/2014 07:06 PM, Susan Cassidy wrote:
>
>> Yes, it is the same connection. It is all the same transaction.
>>
>> Susan
>>
>>
>> On
On 04/16/2014 05:24 PM, Susan Cassidy wrote:
I marked it volatile, and still the next time I call the function after
the first insert, using the previous new id as as input parameter, it
still can't "find" the newly inserted id for the next go-round. Nor can
any regular SELECTs in the main progr
On 04/16/2014 07:06 PM, Susan Cassidy wrote:
Yes, it is the same connection. It is all the same transaction.
Susan
On Wed, Apr 16, 2014 at 5:00 PM, John R Pierce mailto:pie...@hogranch.com>> wrote:
On 4/16/2014 4:53 PM, Susan Cassidy wrote:
Well, it isn't working for me right no
On 04/16/2014 05:24 PM, Susan Cassidy wrote:
I marked it volatile, and still the next time I call the function after
the first insert, using the previous new id as as input parameter, it
still can't "find" the newly inserted id for the next go-round. Nor can
any regular SELECTs in the main progr
I marked it volatile, and still the next time I call the function after the
first insert, using the previous new id as as input parameter, it still
can't "find" the newly inserted id for the next go-round. Nor can any
regular SELECTs in the main program find it.
Susan
On Wed, Apr 16, 2014 at 5:
It isn't marked as one of those as all, so whatever the default is.
That could be it. I'll look up the default.
Thanks,
Susan
On Wed, Apr 16, 2014 at 5:17 PM, Tom Lane wrote:
> Susan Cassidy writes:
> > It is a fairly large and complex Perl program, so no, not really.
> > I do an insert via
Susan Cassidy writes:
> It is a fairly large and complex Perl program, so no, not really.
> I do an insert via a function, which returns the new id, then later I try
> to SELECT on that id, and it doesn't find it.
> Could it be because the insert is done inside a function?
Is the SELECT also ins
It seems to be returning the right id. It should be next for the serial
datatype.
Susan
On Wed, Apr 16, 2014 at 5:13 PM, Bosco Rama wrote:
> On 04/16/14 17:08, Susan Cassidy wrote:
> > The function does a select to see if the id number exists, and it fails.
> > NOT FOUND causes a RAISE EXCEPT
Not to say that perl and complex are redundant, but does the id go away
after the NOT FOUND exception?
On 04/16/2014 06:08 PM, Susan Cassidy wrote:
The function does a select to see if the id number exists, and it
fails. NOT FOUND causes a RAISE EXCEPTION.
Susan
On Wed, Apr 16, 2014 at 5:
On 04/16/14 17:08, Susan Cassidy wrote:
> The function does a select to see if the id number exists, and it fails.
> NOT FOUND causes a RAISE EXCEPTION.
Is it returning the right id? I seem to remember a recent thread
about Perl DBI returning the wrong id's for certain operations.
Just at though
The function does a select to see if the id number exists, and it fails.
NOT FOUND causes a RAISE EXCEPTION.
Susan
On Wed, Apr 16, 2014 at 5:05 PM, Susan Cassidy <
susan.cass...@decisionsciencescorp.com> wrote:
> It is a fairly large and complex Perl program, so no, not really.
>
> I do an inse
It is a fairly large and complex Perl program, so no, not really.
I do an insert via a function, which returns the new id, then later I try
to SELECT on that id, and it doesn't find it.
Could it be because the insert is done inside a function?
Susan
On Wed, Apr 16, 2014 at 4:58 PM, Steven Schl
Yes, it is the same connection. It is all the same transaction.
Susan
On Wed, Apr 16, 2014 at 5:00 PM, John R Pierce wrote:
> On 4/16/2014 4:53 PM, Susan Cassidy wrote:
>
>> Well, it isn't working for me right now. It can't "see" a row that was
>> inserted earlier in the transaction. It is
On 4/16/2014 4:53 PM, Susan Cassidy wrote:
Well, it isn't working for me right now. It can't "see" a row that
was inserted earlier in the transaction. It is a new primary key, and
when I SELECT it, it isn't found.
are you using the same connection ? it won't be visible to a different
con
>> On Wed, Apr 16, 2014 at 4:31 PM, Tom Lane wrote:
>> Susan Cassidy writes:
>> > Is there any way to let a transaction "see" the inserts that were done
>> > earlier in the transaction?
>>
>> It works that way automatically, as long as you're talking about separate
>> statements within one tra
Well, it isn't working for me right now. It can't "see" a row that was
inserted earlier in the transaction. It is a new primary key, and when I
SELECT it, it isn't found.
Susan
On Wed, Apr 16, 2014 at 4:31 PM, Tom Lane wrote:
> Susan Cassidy writes:
> > Is there any way to let a transaction
Susan Cassidy writes:
> Is there any way to let a transaction "see" the inserts that were done
> earlier in the transaction?
It works that way automatically, as long as you're talking about separate
statements within one transaction.
regards, tom lane
--
Sent via pgsql
On Apr 16, 2014, at 4:27 PM, Susan Cassidy
wrote:
> Is there any way to let a transaction "see" the inserts that were done
> earlier in the transaction? I want to insert a row, then later use it within
> the same transaction.
>
> If not, I will have to commit after each insert, and I don't
Is there any way to let a transaction "see" the inserts that were done
earlier in the transaction? I want to insert a row, then later use it
within the same transaction.
If not, I will have to commit after each insert, and I don't want to do
that until add the rows are added, if I can possibly av
Hi Adrian:
On Sun, Apr 6, 2014 at 5:05 PM, Adrian Klaver wrote:
> On 04/06/2014 05:30 AM, Francisco Olarte wrote:
>> I think a trigger is overkill for just a simple data-combining
>> procedure. JMO, but I prefere to reserve triggers for htings which
>> need them.
> Well the flip side to that arg
On 04/06/2014 05:30 AM, Francisco Olarte wrote:
Hi Adrian:
On Sun, Apr 6, 2014 at 2:30 AM, Adrian Klaver wrote:
Still think this is something for a BEFORE INSERT TRIGGER:
I think a trigger is overkill for just a simple data-combining
procedure. JMO, but I prefere to reserve triggers for hti
Hi Adrian:
On Sun, Apr 6, 2014 at 2:30 AM, Adrian Klaver wrote:
> Still think this is something for a BEFORE INSERT TRIGGER:
I think a trigger is overkill for just a simple data-combining
procedure. JMO, but I prefere to reserve triggers for htings which
need them.
Regards.
Francisco Olarte
Hi:
On Sun, Apr 6, 2014 at 2:14 AM, Ben Hoyt wrote:
> Thanks for the info, Francisco and Alban -- that looks useful.
May be.
> Can you see a good way in the INSERT to combine VALUES with that nextval()
> subquery? As there are some columns that are distinct for each row, and some
> that are t
On 06 Apr 2014, at 2:14, Ben Hoyt wrote:
> Thanks for the info, Francisco and Alban -- that looks useful.
>
> Can you see a good way in the INSERT to combine VALUES with that nextval()
> subquery? As there are some columns that are distinct for each row, and some
> that are the same or program
On 04/05/2014 05:14 PM, Ben Hoyt wrote:
Thanks for the info, Francisco and Alban -- that looks useful.
Can you see a good way in the INSERT to combine VALUES with that
nextval() subquery? As there are some columns that are distinct for each
row, and some that are the same or programmatically gen
Thanks for the info, Francisco and Alban -- that looks useful.
Can you see a good way in the INSERT to combine VALUES with that nextval()
subquery? As there are some columns that are distinct for each row, and
some that are the same or programmatically generated for each row. For
instance, there's
On 3 April 2014 16:41, Ben Hoyt wrote:
> Hi folks,
> I tried using currval() to see if that'd work, but it gave an error, I guess
> because I was using it multiple times per session.
currval() requires that nextval() was called before it (either
automatically or explicitly) in the same transacti
1 - 100 of 485 matches
Mail list logo
