Re: [HACKERS] make async slave to wait for lsn to be replayed

On Mon, Oct 30, 2017 at 7:25 PM, Ivan Kartyshov wrote: > It sounds reasonable. I can offer the following version. > > WAIT LSN lsn_number; > WAIT LSN lsn_number TIMEOUT delay; > WAIT LSN lsn_number INFINITE; > WAIT LSN lsn_number NOWAIT; > > > WAIT [token]

Re: [HACKERS] make async slave to wait for lsn to be replayed

Ants Aasma писал 2017-10-26 17:29: On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov wrote: Ants Aasma писал 2017-09-26 13:00: Exposing this interface as WAITLSN will encode that visibility order matches LSN order. This removes any chance of fixing for example

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Thu, Oct 26, 2017 at 4:29 PM, Ants Aasma wrote: > If the UI > were something like "WAITVISIBILITY token", then we can later change > the token to something other than LSN. That assumes, probably optimistically, that nobody will develop a dependency on it being, precisely,

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov wrote: > Ants Aasma писал 2017-09-26 13:00: >> >> Exposing this interface as WAITLSN will encode that visibility order >> matches LSN order. This removes any chance of fixing for example >> visibility order of

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Sep 26, 2017 at 12:00 PM, Ants Aasma wrote: > Exposing this interface as WAITLSN will encode that visibility order > matches LSN order. That would be a bad thing to encode because it doesn't. Well... actually on the standby it does, and that's the only thing that

Re: [HACKERS] make async slave to wait for lsn to be replayed

Alexander Korotkov писал 2017-10-23 13:19: Despite code cleanup, you still have some random empty lines removals in your patch. I reconfigured my IDE to avoid this in the future. -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Mon, Oct 23, 2017 at 12:42 PM, Ivan Kartyshov wrote: > New little cleanup code changes > Despite code cleanup, you still have some random empty lines removals in your patch. @@ -149,7 +150,6 @@ const struct config_enum_entry sync_method_options[] = { > {NULL,

Re: [HACKERS] make async slave to wait for lsn to be replayed

New little cleanup code changes -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Companycommit 217f842726531edb1b0056a5c5727ab01bab7f9b Author: i.kartyshov Date: Mon Oct 23 12:08:59 2017 +0300 Cherry picked and ported

Re: [HACKERS] make async slave to wait for lsn to be replayed

Alexander Korotkov писал 2017-09-26 12:07: I propose following syntax options. WAITLSN lsn; WAITLSN lsn TIMEOUT delay; WAITLSN lsn INFINITE; WAITLSN lsn NOWAIT; For me that looks rather better. What do you think? I agree with you, now syntax looks better. New patch attached to tha mail.

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Aug 15, 2017 at 5:00 AM, Craig Ringer wrote: > On 22 March 2017 at 01:17, Robert Haas wrote: >> >> On Sun, Mar 12, 2017 at 10:20 PM, Thomas Munro >> wrote: >> > Maybe someone can think of a clever way for an

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Mon, Jan 23, 2017 at 2:56 PM, Ivan Kartyshov wrote: > How to use it > == > WAITLSN ‘LSN’ [, timeout in ms]; > WAITLSN_INFINITE ‘LSN’; > WAITLSN_NO_WAIT ‘LSN’; Adding suffix to the command name looks weird. We don't do so for any other command. I propose

Re: [HACKERS] make async slave to wait for lsn to be replayed

I forget to include patch in last letter. Craig Ringer wrote 2017-08-15 05:00: That ship sailed a long time ago unfortunately, they're all over pg_stat_replication and pg_replication_slots and so on. They're already routinely used for monitoring replication lag in bytes, waiting for a peer to

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hello, thank you for your comments over main idea and code. On 13.03.2017 05:20, Thomas Munro wrote: 1) First, I'll restate my view of the syntax-vs-function question: I think an fmgr function is the wrong place to do this, because it doesn't work for our 2 higher isolation levels as

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On Mon, Aug 28, 2017 at 7:57 AM, Craig Ringer wrote: > I'm frequently debugging postmasters that are around long enough. Deadlocks, > etc. > > It's also way easier to debug shmem related issues with a live postmaster vs > a core. Yeah. I don't *frequently* debug

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On 28 August 2017 at 19:45, Tom Lane wrote: > Craig Ringer writes: > > It's a pain having to find the postmaster command line to get the port > > pg_regress started a server on. We print the port in the pg_regress > output, > > why not the socket

Re: [HACKERS] Make pg_regress print a connstring with sockdir

Craig Ringer writes: > It's a pain having to find the postmaster command line to get the port > pg_regress started a server on. We print the port in the pg_regress output, > why not the socket directory / host? I'm not following the point here. The test postmaster isn't

Re: [HACKERS] Make pg_regress print a connstring with sockdir

Craig Ringer wrote: > On 28 August 2017 at 15:19, Michael Paquier > wrote: > > > On Mon, Aug 28, 2017 at 4:07 PM, Craig Ringer > > wrote: > > > == starting postmaster== > > > running with PID 30235;

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On 28 August 2017 at 15:19, Michael Paquier wrote: > On Mon, Aug 28, 2017 at 4:07 PM, Craig Ringer > wrote: > > == starting postmaster== > > running with PID 30235; connect with: > > psql

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On Mon, Aug 28, 2017 at 4:07 PM, Craig Ringer wrote: > == starting postmaster== > running with PID 30235; connect with: > psql "host='/tmp/pg_regress-j74yFE' port=50848 dbname='regression'" > == creating database

Re: [HACKERS] Make pg_regress print a connstring with sockdir

== starting postmaster== running with PID 30235; connect with: psql "host='/tmp/pg_regress-j74yFE' port=50848 dbname='regression'" == creating database "regression" == On 28 August 2017 at 14:08, Michael Paquier

Re: [HACKERS] Make pg_regress print a connstring with sockdir

On Mon, Aug 28, 2017 at 2:28 PM, Craig Ringer wrote: > It's a pain having to find the postmaster command line to get the port > pg_regress started a server on. We print the port in the pg_regress output, > why not the socket directory / host? > > How about > running on

[HACKERS] Make pg_regress print a connstring with sockdir

Hi all It's a pain having to find the postmaster command line to get the port pg_regress started a server on. We print the port in the pg_regress output, why not the socket directory / host? How about running on 'port=50848 host=/tmp/pg_regress-UMrcT3' with PID 16409 per the attached? If

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 22 March 2017 at 01:17, Robert Haas wrote: > On Sun, Mar 12, 2017 at 10:20 PM, Thomas Munro > wrote: > > Maybe someone can think of a clever way for an extension to insert a > > wait for a user-supplied LSN *before* acquiring a snapshot

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 3/9/17 07:49, Ivan Kartyshov wrote: > Here I attached rebased patch waitlsn_10dev_v3 (core feature) > I will leave the choice of implementation (core/contrib) to the > discretion of the community. This patch is registered in the upcoming commit fest, but it needs to be rebased. -- Peter

Re: [HACKERS] "make check" with non-GNU make

Thomas Munro writes: > On Wed, Aug 9, 2017 at 3:44 PM, Tom Lane wrote: >> Hmm, looking into Makefile.global.in, that step seems to be conditional on >> MAKELEVEL: > Ah, right. That coding is recommended in the GNU make manual to > distinguish

Re: [HACKERS] "make check" with non-GNU make

On Wed, Aug 9, 2017 at 3:44 PM, Tom Lane wrote: > Thomas Munro writes: >> Does anyone know why "make check" doesn't work on BSD systems if >> tmp_install doesn't exist yet? It's no big deal, you just have to run >> "gmake check", but Makefile

Re: [HACKERS] "make check" with non-GNU make

Thomas Munro writes: > Does anyone know why "make check" doesn't work on BSD systems if > tmp_install doesn't exist yet? It's no big deal, you just have to run > "gmake check", but Makefile is supposed to do that for you and it > works fine for every other target.

[HACKERS] "make check" with non-GNU make

Hi hackers, Does anyone know why "make check" doesn't work on BSD systems if tmp_install doesn't exist yet? It's no big deal, you just have to run "gmake check", but Makefile is supposed to do that for you and it works fine for every other target. No big deal, but it'd be nice to unravel this

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 11 June 2017 at 20:19, Tom Lane wrote: >> The standard way of doing this is to calculate the "standard error" of >> the sample proportion - see, for example [3], [4]: >> SE = sqrt(p*(1-p)/n) >> Note, however, that this formula assumes that the sample size n is >> small

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

Dean Rasheed writes: > I think we should attempt to come up with a more principled approach > to this, taking into account the table and sample sizes. Here's what I > found, after a bit of research: Thanks for doing some legwork on this! > A common initial rule of

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 05/06/17 09:30, Tom Lane wrote: > First, I think we need a larger hard floor on the number of occurrences > of a value that're required to make ANALYZE decide it is a "most common > value"... > > Second, the code also has a rule that potential MCVs need to have an > estimated frequency at least

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 06/06/17 10:12, Gavin Flower wrote: On 06/06/17 09:41, Mark Kirkwood wrote: On 05/06/17 09:30, Tom Lane wrote: I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that there

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

Gavin Flower wrote: > The standard deviation (sd) is proportional to the square root of > the number in the sample in a Normal Distribution. > > In a Normal Distribution, about 2/3 the values will be within plus > or minus one sd of the mean. > > There seems to be an implicit assumption that

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On Mon, Jun 5, 2017 at 3:34 PM, Tom Lane wrote: > I think that a single count in a 30K-row sample is noise by definition. Not if the table only *has* 30K rows. Or even 100K. And anyway we're talking about what to do with a value we hit at least twice, which is not quite the

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 06/06/17 10:12, Gavin Flower wrote: On 06/06/17 09:41, Mark Kirkwood wrote: On 05/06/17 09:30, Tom Lane wrote: I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that there

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 06/06/17 09:41, Mark Kirkwood wrote: On 05/06/17 09:30, Tom Lane wrote: I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that there are a couple of things we ought to do

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 05/06/17 09:30, Tom Lane wrote: I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that there are a couple of things we ought to do about it. First, I think we need a larger

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

Robert Haas writes: > On Sun, Jun 4, 2017 at 5:30 PM, Tom Lane wrote: >> First, I think we need a larger hard floor on the number of occurrences >> of a value that're required to make ANALYZE decide it is a "most common >> value". > This kind of math

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On Sun, Jun 4, 2017 at 5:30 PM, Tom Lane wrote: > I've been thinking about the behavior discussed in > https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org > and it seems to me that there are a couple of things we ought to do about >

Re: [HACKERS] make check false success

On Mon, Jun 5, 2017 at 5:23 AM, Sandro Santilli wrote: > Why not ? The caller is attempting to make an unsupported target, > how's that different from calling `make unexistent` ? That's a good point, but what Tom wrote is along the lines of my concerns also, especially his last

Re: [HACKERS] make check false success

Sandro Santilli writes: > On Fri, Jun 02, 2017 at 08:20:25AM -0400, Robert Haas wrote: >> On Thu, Jun 1, 2017 at 10:18 AM, Sandro Santilli wrote: >>> I noticed that the `check` Makefile rule imported by PGXS is giving >>> a success exit code even when it is unsupported.

Re: [HACKERS] make check false success

On Fri, Jun 02, 2017 at 08:20:25AM -0400, Robert Haas wrote: > On Thu, Jun 1, 2017 at 10:18 AM, Sandro Santilli wrote: > > I noticed that the `check` Makefile rule imported by PGXS is giving > > a success exit code even when it is unsupported. > > > > The attached patch fixes that. >

[HACKERS] Make ANALYZE more selective about what is a "most common value"?

I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that there are a couple of things we ought to do about it. First, I think we need a larger hard floor on the number of occurrences

Re: [HACKERS] make check false success

On Thu, Jun 1, 2017 at 10:18 AM, Sandro Santilli wrote: > I noticed that the `check` Makefile rule imported by PGXS is giving > a success exit code even when it is unsupported. > > The attached patch fixes that. Hmm. I'm not 100% sure that the existing behavior is wrong. --

[HACKERS] make check false success

I noticed that the `check` Makefile rule imported by PGXS is giving a success exit code even when it is unsupported. The attached patch fixes that. --strk; () Free GIS & Flash consultant/developer /\ https://strk.kbt.io/services.html >From 43fa28f141871a6efdd3e5d0c9ec8cc537585ff5 Mon

Re: [HACKERS] Make defines in pg_config_manual.h conditional?

Andres Freund writes: > ATM the defines in pg_config_manual.h are largely unconditional - which > means the file has to be edited instead of being able to override things > via CFLAGS/COPT. Is there any good reason for doing so? YES. If you do things like that, the

[HACKERS] Make defines in pg_config_manual.h conditional?

Hi, ATM the defines in pg_config_manual.h are largely unconditional - which means the file has to be edited instead of being able to override things via CFLAGS/COPT. Is there any good reason for doing so? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list

Re: [HACKERS] make check-world output

On Mon, Apr 03, 2017 at 03:03:44PM +0900, Michael Paquier wrote: > On Sat, Apr 1, 2017 at 4:28 PM, Noah Misch wrote: > > The pg_upgrade test suite originated in an age when "make check-world" was > > forbidden to depend on Perl; the choice was a shell script or a C program. >

Re: [HACKERS] make check-world output

On Sat, Apr 1, 2017 at 4:28 PM, Noah Misch wrote: > The pg_upgrade test suite originated in an age when "make check-world" was > forbidden to depend on Perl; the choice was a shell script or a C program. We > do maintain vcregress.pl:upgradecheck(), a Windows-specific Perl

Re: [HACKERS] make check-world output

On Sat, Mar 11, 2017 at 11:14:36AM -0500, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> What about just reverting 2f227656076a? > > > That works for me too, if we think we no longer need that level of > > detail. > > A general issue with this sort

Re: [HACKERS] make check-world output

On 3/10/17 19:15, Jeff Janes wrote: > Should --enable-tap-tests be mentioned in "32.1.3. Additional Test > Suites"? Or at least cross-referenced from "32.4. TAP Tests"? Done. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] make check-world output

On 3/13/17 05:35, Dagfinn Ilmari Mannsåker wrote: > Another thing I noticed is that there's a bunch of 'diag' calls in the > tests scripts (particularly ssl/t/001_ssltests.pl and > recovery/t/001_stream_rep.pl) that should probably be 'note's instead, > so they don't pollute STDERR in non-verbose

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi Ivan, On 3/21/17 1:06 PM, David Steele wrote: Hi Ivan, On 3/12/17 10:20 PM, Thomas Munro wrote: On Fri, Mar 10, 2017 at 1:49 AM, Ivan Kartyshov wrote: Here I attached rebased patch waitlsn_10dev_v3 (core feature) I will leave the choice of implementation

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Sun, Mar 12, 2017 at 10:20 PM, Thomas Munro wrote: > Maybe someone can think of a clever way for an extension to insert a > wait for a user-supplied LSN *before* acquiring a snapshot so it can > work for the higher levels, or maybe the hooks should go into core >

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi Ivan, On 3/12/17 10:20 PM, Thomas Munro wrote: On Fri, Mar 10, 2017 at 1:49 AM, Ivan Kartyshov wrote: Here I attached rebased patch waitlsn_10dev_v3 (core feature) I will leave the choice of implementation (core/contrib) to the discretion of the community. Will

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 6:19 PM, Tom Lane wrote: > Alvaro Herrera writes: > > Jeff Janes wrote: > >> There was some recent discussion about making "make check-world" faster. > >> I'm all for that, but how about making it quieter? On both machines >

Re: [HACKERS] make check-world output

Tom Lane writes: > For the basic build process, we've largely solved that through the > use of "make -s". But we don't really have a comparable "be quiet" > option for test runs, especially not the TAP tests. Maybe we need > to think a bit more globally about what it is

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Fri, Mar 10, 2017 at 1:49 AM, Ivan Kartyshov wrote: > Here I attached rebased patch waitlsn_10dev_v3 (core feature) > I will leave the choice of implementation (core/contrib) to the discretion > of the community. > > Will be glad to hear your suggestion about

Re: [HACKERS] make check-world output

Alvaro Herrera writes: > Tom Lane wrote: >> What about just reverting 2f227656076a? > That works for me too, if we think we no longer need that level of > detail. A general issue with this sort of messaging is that when things are working more or less normally, you'd

Re: [HACKERS] make check-world output

Tom Lane wrote: > Alvaro Herrera writes: > > Jeff Janes wrote: > >> There was some recent discussion about making "make check-world" faster. > >> I'm all for that, but how about making it quieter? On both machines I've > >> run it on (CentOS6.8 and Ubuntu 16.04.2), it

Re: [HACKERS] make check-world output

On 3/10/17 19:26, Jeff Janes wrote: > and there will be an exit code. > > > True. But I generally don't rely on that, unless the docs explicitly > tell me to. > > > If we show no output, then other people will complain that they can't > tell whether it's hanging. > > > Isn't

Re: [HACKERS] make check-world output

Alvaro Herrera writes: > Jeff Janes wrote: >> There was some recent discussion about making "make check-world" faster. >> I'm all for that, but how about making it quieter? On both machines I've >> run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some gibberish to >>

Re: [HACKERS] make check-world output

Jeff Janes wrote: > There was some recent discussion about making "make check-world" faster. > I'm all for that, but how about making it quieter? On both machines I've > run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some gibberish to > stderr, example attached. I think you're complaining

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 4:00 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/10/17 15:05, Jeff Janes wrote: > > There was some recent discussion about making "make check-world" > > faster. I'm all for that, but how about making it quieter? On both > > machines I've run it

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 12:24 PM, Alvaro Herrera wrote: > Jeff Janes wrote: > > > Also, it runs in about 8 minutes, not the 20 minutes reported by others. > > My system is virtualized, and not particularly fast. I wonder if it is > > failing early somewhere without

Re: [HACKERS] make check-world output

On 3/10/17 15:24, Alvaro Herrera wrote: > Jeff Janes wrote: > >> Also, it runs in about 8 minutes, not the 20 minutes reported by others. >> My system is virtualized, and not particularly fast. I wonder if it is >> failing early somewhere without running to completion? How would/should I >>

Re: [HACKERS] make check-world output

On 3/10/17 15:05, Jeff Janes wrote: > There was some recent discussion about making "make check-world" > faster. I'm all for that, but how about making it quieter? On both > machines I've run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some > gibberish to stderr, example attached. Which

Re: [HACKERS] make check-world output

Jeff Janes wrote: > Also, it runs in about 8 minutes, not the 20 minutes reported by others. > My system is virtualized, and not particularly fast. I wonder if it is > failing early somewhere without running to completion? How would/should I > know? Maybe you don't have --enable-tap-tests? --

[HACKERS] make check-world output

There was some recent discussion about making "make check-world" faster. I'm all for that, but how about making it quieter? On both machines I've run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some gibberish to stderr, example attached. Which first made me wonder whether the test passed or

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hello On 07.03.2017 15:58, Masahiko Sawada wrote: I've read the discussion so far but I didn't see the reason why you've changed it to as a contrib module. Could you tell me about that? I did it on the initiative of our customer, who preferred the implementation in the form of contrib.

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Wed, Mar 8, 2017 at 1:58 AM, Masahiko Sawada wrote: > On Tue, Mar 7, 2017 at 8:48 PM, Ivan Kartyshov > wrote: >> Rebase done. > > Thank you for updating the patch. > >> >> Meanwhile I made some more changes. >> >> Changes >> === >> 1)

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Mar 7, 2017 at 8:48 PM, Ivan Kartyshov wrote: > Rebase done. Thank you for updating the patch. > > Meanwhile I made some more changes. > > Changes > === > 1) WAITLSN is now implemented as an extension called "pg_waitlsn" I've read the discussion so far

Re: [HACKERS] make async slave to wait for lsn to be replayed

Rebase done. Meanwhile I made some more changes. Changes === 1) WAITLSN is now implemented as an extension called "pg_waitlsn" 2) Call new hook "lsn_updated_hook" right after xact_redo_commit (xlog.c) 3) Corresponding functions: pg_waitlsn('0/693FF800', 1) - wait 10 seconds

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi Ivan, On 2/27/17 3:52 PM, Thomas Munro wrote: > On Thu, Feb 23, 2017 at 3:08 AM, Thom Brown wrote: >> On 23 January 2017 at 11:56, Ivan Kartyshov >> wrote: >>> >>> Thank you for reading, will be glad to get your feedback. >> >> Could you please

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Thu, Feb 23, 2017 at 3:08 AM, Thom Brown wrote: > On 23 January 2017 at 11:56, Ivan Kartyshov > wrote: >> >> Thank you for reading, will be glad to get your feedback. > > Could you please rebase your patch as it no longer applies cleanly. +1 --

Re: [HACKERS] Make subquery alias optional in FROM clause

On 2017-02-24 07:25, Robert Haas wrote: > I don't think it's only Oracle that allows omitting the > alias; I think there are a number of other systems that behave > similarly. SQLite, for example. Making conversions from SQLite to Postgres easier is a Good Thing. "subquery in FROM must have an

Re: [HACKERS] Make subquery alias optional in FROM clause

On Fri, Feb 24, 2017 at 9:35 AM, David Fetter wrote: > > > => SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x; > > ERROR: 42703: column "?column" does not exist > > LINE 2: SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x; > >^ > > HINT:

Re: [HACKERS] Make subquery alias optional in FROM clause

On Thu, Feb 23, 2017 at 01:27:29PM +, Greg Stark wrote: > On 22 February 2017 at 15:08, Tom Lane wrote: > > Indeed. When I wrote the comment you're referring to, quite a few years > > ago now, I thought that popular demand might force us to allow omitted > > aliases. But

Re: [HACKERS] Make subquery alias optional in FROM clause

Craig Ringer writes: > Personally I think we need to generate one, if nothing else for error > messages where we try to emit qualified names of columns. Also for EXPLAIN, where there has to be a way to name everything. > But I don't see that the name needs to be anything

Re: [HACKERS] Make subquery alias optional in FROM clause

On Fri, Feb 24, 2017 at 1:04 PM, Craig Ringer wrote: > On 23 February 2017 at 22:20, Tom Lane wrote: >>> * Don't force/generate an alias at all. >> >>> I've no idea for this yet and Tom already was concerned what this might >>> break. There are several

Re: [HACKERS] Make subquery alias optional in FROM clause

On 23 February 2017 at 22:20, Tom Lane wrote: >> * Don't force/generate an alias at all. > >> I've no idea for this yet and Tom already was concerned what this might >> break. There are several places in the transform phase where the >> refnames are required (e.g.

Re: [HACKERS] Make subquery alias optional in FROM clause

On Thu, Feb 23, 2017 at 4:08 PM, Pantelis Theodosiou wrote: > Question: Will the patch be removed if and when Oracle decides to be > compatible with the standard and forbids non-aliased derived tables? > > (I know it's a rather theoretical question. Unlikely that Oracle breaks

Re: [HACKERS] Make subquery alias optional in FROM clause

On Thu, Feb 23, 2017 at 7:50 PM, Tom Lane wrote: > Maybe the best answer is to not do it immediately when transforming the > subselect's RTE, but to go back after we've finished transforming the > entire FROM clause and add aliases to any RTEs that lack them. I think >

Re: [HACKERS] Make subquery alias optional in FROM clause

On Thu, Feb 23, 2017 at 10:37:16AM +0100, Bernd Helmle wrote: > Am Mittwoch, den 22.02.2017, 22:17 -0500 schrieb Tom Lane: > > [ shrug... ]  Well, I won't resist this hard as long as it's done > > competently, which to me means "the subquery name doesn't conflict > > with > > anything else".  Not

Re: [HACKERS] Make subquery alias optional in FROM clause

Bernd Helmle writes: > Right, i'm going to give it a try then. Currently i see these options: > * Validate any generated alias against a list of explicit alias names. > This means we have to collect explicit alias names in, say a hashtable, > and validate a generated name

Re: [HACKERS] Make subquery alias optional in FROM clause

Greg Stark writes: > On 22 February 2017 at 15:08, Tom Lane wrote: >> Indeed. When I wrote the comment you're referring to, quite a few years >> ago now, I thought that popular demand might force us to allow omitted >> aliases. But the demand never

Re: [HACKERS] Make subquery alias optional in FROM clause

On 23 February 2017 at 13:27, Greg Stark wrote: > => SELECT "?column"? FROM (select 1+1 as "?column?", 1+1) AS x; Oops, I missed the typo there: => SELECT "?column?" FROM (select 1+1 AS "?column?", 1+1) AS x; ERROR: 42702: column reference "?column?" is ambiguous LINE 2: SELECT

Re: [HACKERS] Make subquery alias optional in FROM clause

On 22 February 2017 at 15:08, Tom Lane wrote: > Indeed. When I wrote the comment you're referring to, quite a few years > ago now, I thought that popular demand might force us to allow omitted > aliases. But the demand never materialized. At this point it seems > clear to

Re: [HACKERS] Make subquery alias optional in FROM clause

On Thu, Feb 23, 2017 at 3:17 AM, Tom Lane wrote: > Robert Haas writes: > > On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams > wrote: > >> I suspect most users, like me, just roll their eyes, grumble, and put up > >> with it

Re: [HACKERS] Make subquery alias optional in FROM clause

Am Mittwoch, den 22.02.2017, 22:17 -0500 schrieb Tom Lane: > [ shrug... ]  Well, I won't resist this hard as long as it's done > competently, which to me means "the subquery name doesn't conflict > with > anything else".  Not "it doesn't conflict unless you're unlucky > enough > to have used the

Re: [HACKERS] Make subquery alias optional in FROM clause

Robert Haas writes: > On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote: >> I suspect most users, like me, just roll their eyes, grumble, and put up >> with it rather than complain. It's a pain point, but tolerable enough >> that no one bothers

Re: [HACKERS] Make subquery alias optional in FROM clause

On 2017-02-23 08:21:41 +0530, Robert Haas wrote: > On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote: > > On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote: > >> Bernd Helmle writes: > >> >> From time to time, especially during migration

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, Feb 22, 2017 at 10:33 PM, Nico Williams wrote: > On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote: >> Bernd Helmle writes: >> >> From time to time, especially during migration projects from Oracle to >> > PostgreSQL, i'm faced with

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, 2017-02-22 at 08:13 -0700, David G. Johnston wrote: > I'll contribute to the popular demand aspect but given that the error > is > good and the fix is very simple its not exactly a strong desire. In one project i've recently seen, for some reasons, they need to maintain an application

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, Feb 22, 2017 at 10:08:38AM -0500, Tom Lane wrote: > Bernd Helmle writes: > >> From time to time, especially during migration projects from Oracle to > > PostgreSQL, i'm faced with people questioning why the alias in the FROM > > clause for subqueries in PostgreSQL is

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, 2017-02-22 at 10:08 -0500, Tom Lane wrote: > > Indeed.  When I wrote the comment you're referring to, quite a few > years > ago now, I thought that popular demand might force us to allow > omitted > aliases.  But the demand never materialized.  At this point it seems > clear to me that

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote: > Or else not generate > a name at all, in which case there simply wouldn't be a way to refer to > the subquery by name; I'm not sure what that might break though. > ​Yeah, usually when I want this I don't end up needing refer

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, Feb 22, 2017 at 8:08 AM, Tom Lane wrote: > Bernd Helmle writes: > >> From time to time, especially during migration projects from Oracle to > > PostgreSQL, i'm faced with people questioning why the alias in the FROM > > clause for subqueries in

Re: [HACKERS] Make subquery alias optional in FROM clause

Bernd Helmle writes: >> From time to time, especially during migration projects from Oracle to > PostgreSQL, i'm faced with people questioning why the alias in the FROM > clause for subqueries in PostgreSQL is mandatory. The default answer > here is, the SQL standard

[HACKERS] Make subquery alias optional in FROM clause

>From time to time, especially during migration projects from Oracle to PostgreSQL, i'm faced with people questioning why the alias in the FROM clause for subqueries in PostgreSQL is mandatory. The default answer here is, the SQL standard requires it. This also is exactly the comment in our

  1   2   3   4   5   6   7   >