Le jeu. 6 févr. 2020 à 03:55, Vik Fearing a
écrit :
> Hello,
>
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
>
> The effect of this is:
>
> - nothing at all when not in a transaction,
>
Too bad it doesn't add a space, so that we still have the same space used
byt the
On Thu, 2020-02-06 at 03:54 +0100, Vik Fearing wrote:
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
+1
Yours,
Laurenz Albe
+1
(+10 billion actually, but sadly, I'm only allowed a +1)
On Thu, Feb 6, 2020 at 4:55 AM Vik Fearing wrote:
> Hello,
>
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
>
> The effect of this is:
>
> - nothing at all when not in a transaction,
> - adding a '*' when in
On Wed, Feb 5, 2020 at 7:55 PM Vik Fearing wrote:
> Please answer +1 if you want or don't mind seeing transaction status by
> default in psql or -1 if you would prefer to keep the current default.
>
+1
On 2/5/20 8:05 PM, Vik Fearing wrote:
On 06/02/2020 04:55, Steve Baldwin wrote:
Hi Vik,
I'm not sure why this should be the default when it is easy to override the
default via a psqrc file. If you know enough to do it, you can.
Because it isn't always easy to modify the .psqlrc file. This
On Thu, Feb 06, 2020 at 03:54:48AM +0100, Vik Fearing wrote:
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
>
> The effect of this is:
>
> - nothing at all when not in a transaction,
> - adding a '*' when in a transaction or a '!' when in an aborted
> transaction.
>
> On Feb 5, 2020, at 18:54, Vik Fearing wrote:
> Please answer +1 if you want or don't mind seeing transaction status by
> default in psql or -1 if you would prefer to keep the current default.
+1.
On 06/02/20 8:24 am, Vik Fearing wrote:
Hello,
I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
The effect of this is:
- nothing at all when not in a transaction,
- adding a '*' when in a transaction or a '!' when in an aborted
transaction.
Before making a change
On 06/02/2020 04:55, Steve Baldwin wrote:
> Hi Vik,
>
> I'm not sure why this should be the default when it is easy to override the
> default via a psqrc file. If you know enough to do it, you can.
Because it isn't always easy to modify the .psqlrc file. This is
especially true if you
Hi Vik,
I'm not sure why this should be the default when it is easy to override the
default via a psqrc file. If you know enough to do it, you can. Otherwise I
don't think it adds any value as a default since a novice user isn't going
to know what */!/? means. Maybe I'm missing something.
-1
On Thu, 6 Feb 2020 at 11:55, Vik Fearing wrote:
> Hello,
>
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
>
> The effect of this is:
>
> - nothing at all when not in a transaction,
> - adding a '*' when in a transaction or a '!' when in an aborted
> transaction.
>
>
+1
On Wed, Feb 5, 2020 at 9:15 PM Ahmed, Nawaz (Fuji Xerox Australia)
wrote:
>
> +1
>
> -Original Message-
> From: Vik Fearing
> Sent: Thursday, 6 February 2020 1:55 PM
> To: pgsql-general@lists.postgresql.org
> Subject: POLL: Adding transaction status to default psql prompt
>
> Hello,
+1
-Original Message-
From: Vik Fearing
Sent: Thursday, 6 February 2020 1:55 PM
To: pgsql-general@lists.postgresql.org
Subject: POLL: Adding transaction status to default psql prompt
Hello,
I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
The effect of this is:
+1 of course
On Wed, Feb 5, 2020 at 6:55 PM Vik Fearing wrote:
> Hello,
>
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
>
> The effect of this is:
>
> - nothing at all when not in a transaction,
> - adding a '*' when in a transaction or a '!' when in an aborted
>
Hello,
I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
The effect of this is:
- nothing at all when not in a transaction,
- adding a '*' when in a transaction or a '!' when in an aborted
transaction.
Before making a change to a long-time default, a poll in this group
Greetings,
* Matthias Apitz (g...@unixarea.de) wrote:
> If I look into the database I see:
>
> sisis71=# select rolname, rolpassword from pg_authid where rolname = 'sisis';
> rolname | rolpassword
> -+-
> sisis |
Hi all,
Update cascade apparently doesn't work as well on partiotioned tables (when
moving data between different partitions).
Please, look at example below:
-- Create master partitioned table;
CREATE TABLE users (
id serial NOT NULL,
username text NOT NULL,
Moreno, thank you for all your help.
Following your instructions, I was able to recover my databases. All is
good.
Chris
On Wed, Feb 5, 2020 at 6:45 AM Moreno Andreo
wrote:
> Il 04/02/2020 21:18, Chris Charley ha scritto:
> > Hello Moreno
> >
> > Thanks for the reply!
> >
> > I ran Services
On 2/5/20 12:47 AM, Sonam Sharma wrote:
Version is 11.2 .. took schema dump using pg_dump -d -n (schma) / gunzip ..
So the above was a plain text dump that you then piped through
gunzip(?)? That does not make sense.
The error I am getting while running restore.
If it is a plain text dump
Oh yeah, I must add new *begin ... exception .. end;* block between.
So like this:
BEGIN
>
BEGIN
> EXCEPTION when . then ..
> END;
>
> END;
At first I did like this:
BEGIN
.
EXCEPTION when . then ..;
> END;
Raul
Kontakt hubert depesz lubaczewski () kirjutas kuupäeval
K, 5.
Just refactor DO block to function that returns row set and put SELECT inside.
> 29 дек. 2018 г., в 18:40, Glenn Schultz написал(а):
>
> All,
>
> I need to initialize a variable and then use it in query. Ultimately this
> will part of a recursive CTE but for now I just need to work this out.
On Wed, Feb 05, 2020 at 04:17:09PM +0200, Raul Kaubi wrote:
> Let's say I want my procedure/function to resume work after specific error
> ( duplicate_table ).
> Is it possible to resume work after error..?
> EXCEPTION
> > WHEN duplicate_table then ..;
Sure you can:
Hi
PostgreSQL 12.1
Let's say I want my procedure/function to resume work after specific error
( duplicate_table ).
Is it possible to resume work after error..?
EXCEPTION
> WHEN duplicate_table then ..;
Or is there different approach to achieve that..?
Thanks
Raul
Makes sense yeah.
Thanks for both of your help.
Raul
Kontakt hubert depesz lubaczewski () kirjutas kuupäeval
K, 5. veebruar 2020 kell 14:50:
> On Wed, Feb 05, 2020 at 02:42:42PM +0200, Raul Kaubi wrote:
> > Thanks, it worked!
> >
> > By the way, what does this "**j"* mean there..? (this does
On Wed, Feb 05, 2020 at 02:42:42PM +0200, Raul Kaubi wrote:
> Thanks, it worked!
>
> By the way, what does this "**j"* mean there..? (this does not mean
> multiply there?)
it's normal multiplication.
Your "j" variable is integer.
So, '1 month'::interval * j is some number of months.
> And what
Thanks, it worked!
By the way, what does this "**j"* mean there..? (this does not mean
multiply there?)
And what if, I would like to declare v_to_date also, so that v_to_date is
always + 1 month compared to v_date_from..?
-- This one will work, but can this be done simpler..?
v_to_date :=
Raul Kaubi schrieb am 05.02.2020 um 12:21:
> How can I declare another variable from another variable.
> Basically from oracle, I can just:
>
> var1 := 'asda'||var2;
>
> In postgres, I have the following example, I would like to use variable j to
> add number of months there.
>
> "
On Wed, Feb 5, 2020 at 2:22 PM Raul Kaubi wrote:
>
> DO $$
>> DECLARE
>> v_var integer := 1;
>> v_from_date date;
>> BEGIN
>> for j in 0..v_var LOOP
>> v_from_date := (date_trunc('month',current_date) + interval 'j
>> month')::date;
>> RAISE NOTICE '%', v_from_date;
>> END LOOP;
>> END;
>> $$
On 2020-Feb-05, Nick Renders wrote:
> Is there anything specific I should check in our postgres installation /
> database to make sure it is running ok now? Anyway to see what the
> consequences were of purging that one pg_clog file?
Losing pg_clog files is pretty bad, and should not happen;
Il 04/02/2020 21:18, Chris Charley ha scritto:
Hello Moreno
Thanks for the reply!
I ran Services and it reported postsql as Disabled.
A disabled service will never run nor leave error messages anywhere
Right click on the Postgresql service, select properties.
In the next window, choose
Awesome, thanks!
Kontakt Geoff Winkless () kirjutas kuupäeval K, 5.
veebruar 2020 kell 13:11:
>
>
> On Wed, 5 Feb 2020 at 10:48, Raul Kaubi wrote:
>
>>
>> DO $$
>>> DECLARE
>>> cur cursor for
>>> select * from (values('logi_web'), ('logi_taustaprotsess')) as q (col1);
>>> BEGIN
>>> for i in cur
Hi
PostgreSQL 12.1
How can I declare another variable from another variable.
Basically from oracle, I can just:
> var1 := 'asda'||var2;
In postgres, I have the following example, I would like to use variable j
to add number of months there.
" interval 'j month')::date; "
DO $$
> DECLARE
>
Hello,
Yesterday, we experienced some issues with our Postgres installation
(v9.6 running on macOS 10.12).
It seems that the machine was automatically rebooted for a yet unknown
reason, and afterwards we were unable to start the Postgres service.
The postgres log shows the following:
On Wed, 5 Feb 2020 at 10:48, Raul Kaubi wrote:
>
> DO $$
>> DECLARE
>> cur cursor for
>> select * from (values('logi_web'), ('logi_taustaprotsess')) as q (col1);
>> BEGIN
>> for i in cur LOOP
>> RAISE NOTICE 'create table %_y2020m01 PARTITION OF % FOR VALUES FROM
>> (''2019-12-01'') TO
Hi
PostgreSQL 12.1
I am trying to figure out, how can I get rid of brackets for variable.
Example as follows:
DO $$
> DECLARE
> cur cursor for
> select * from (values('logi_web'), ('logi_taustaprotsess')) as q (col1);
> BEGIN
> for i in cur LOOP
> RAISE NOTICE 'create table %_y2020m01
On 2020-02-05 13:54:56 +0530, Sonam Sharma wrote:
> I am copying schema data to qa box from prod.its failing and giving below
> error
> :
>
>
> WARNING: terminating connection because of crash of another server process
>
> DETAIL: The postmaster has commanded this server process to roll back
Your message
To: pgsql-general@lists.postgresql.org
Subject: Re: The best way to solve a problem
Sent: 05-02-2020 12:48
was read on 05-02-2020 14:51.
binADpolde_6K.bin
Description: message/disposition-notification
You can workaround by simulation autonomous transaction using plpython or
dblink. Or just performing a commit outside the stored procedure.
> On 5. Feb 2020, at 09:06, İlyas Derse wrote:
>
> I'm writing to you about Commit. I want to do force commit query even if I
> have exception.
> It's
Version is 11.2 .. took schema dump using pg_dump -d -n (schma) / gunzip
..
The error I am getting while running restore.
On Wed, Feb 5, 2020, 2:03 PM Rob Sargent wrote:
>
>
> On 2/5/20 1:24 AM, Sonam Sharma wrote:
>
> I am copying schema data to qa box from prod.its failing and giving below
>
On 2/5/20 1:24 AM, Sonam Sharma wrote:
I am copying schema data to qa box from prod.its failing and giving
below error :
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction
I am copying schema data to qa box from prod.its failing and giving below
error :
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process
st 5. 2. 2020 v 9:10 odesílatel İlyas Derse napsal:
> I'm writing to you about Commit. I want to do force commit query even
> if I have exception.
> It's like :
>
> CREATE OR REPLACE PROCEDURE public."test"()
> LANGUAGE 'plpgsql'
> AS $BODY$
> DECLARE "a" integer ;
> DECLARE "b" integer ;
>
I'm writing to you about Commit. I want to do force commit query even if
I have exception.
It's like :
CREATE OR REPLACE PROCEDURE public."test"()
LANGUAGE 'plpgsql'
AS $BODY$
DECLARE "a" integer ;
DECLARE "b" integer ;
BEGIN
"a" = 1;
"b" = 0;
BEGIN
raise notice 'hata';
update
43 matches
Mail list logo
