Re: procedures and plpgsql PERFORM

On Thu, Dec 14, 2017 at 8:22 AM, Merlin Moncure wrote: > On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane wrote: > > Ashutosh Bapat writes: > >> We allow a function to be invoked as part of PERFORM statement in > plpgsql > >>

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 6:26 PM, Craig Ringer wrote: > >> There is also stackexchange question with 51000 views that asks how to >> start the postgresql client. Should we rename psql to mysql to help >> new users too? >> > > Frankly, that's a legit question and I don't

Re: Add %r substitution for psql prompts to show recovery status

On Wed, Dec 6, 2017 at 7:19 PM, Ian Barwick wrote: > A possible alternative would be only to check the status each time a new > database connection is made, but that wouldn't catch the case where the > server has been promoted. > ​Can we cache a false

Re: How to use set/reset role in contrib_regression test?

On Thu, Dec 7, 2017 at 3:55 PM, Jeremy Finzel wrote: > Hello! I hope this is the right list for extension dev questions? > > SELECT CURRENT_ROLE; > current_user > -- > jfinzel > (1 row) > > SET ROLE test_pgl_ddl_deploy; > CREATE SCHEMA special; > CREATE TABLE

Re: proposal: alternative psql commands quit and exit

On Fri, Dec 8, 2017 at 8:09 AM, Ryan Murphy wrote: > ​There isn't going to be that much appetite for this just so that people >> can use PostgreSQL without reading our documentation: or the output of >> typing "help" at the psql prompt that says "type \q to quit".​ >> >>

Re: Logical replication without a Primary Key

On Thursday, December 7, 2017, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/6/17 19:03, Joshua D. Drake wrote: > > > > > How does that work? Is it using one of the hidden columns on a row? > > It means that for example if an update record is produced, the entire > row is

Re: Speeding up pg_upgrade

On Thu, Dec 7, 2017 at 12:04 PM, Stephen Frost wrote: > If you've > got a better idea for that, great, but having certain pg_upgrade > migrations require running ANALYZE and some migrations not require it is > something we need to make users *very* clear about. No, I don't

Re: proposal: alternative psql commands quit and exit

On Tue, Dec 12, 2017 at 8:04 AM, Jeremy Finzel wrote: > I don't think this is a significant stumbling block for users adopting > postgres. > ​The OP complained, and I tend to agree, that 90% of the world uses the command "exit" to end a program and that it would be nice if we

Re: Cost Model

On Wed, Dec 20, 2017 at 10:29 AM, neto brpr wrote: > Any comment, hint about it or something, please inform me. > The docs contain this - its seem to cover what you describe: ​

citext function overloads for text parameters

On Sunday, May 6, 2018, Shay Rojansky wrote: > > > Thanks for the input. It's worth noting that the equality operator > currently works in the same way: citext = text comparison is (surprisingly > for me) case-sensitive. > > My expectation was that since citext is supposed to be a

Re: Allow COPY's 'text' format to output a header

On Mon, May 14, 2018 at 11:44 AM, Garick Hamlin wrote: > I wonder if there was a way to let COPY FROM detect or ignore headers > as appropriate and rather than cause silently result in headers being > added as data. > ​ ​Not reliably​ > Maybe a blank line after the

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, May 10, 2018 at 8:57 AM, Alvaro Herrera wrote: > b) by default, no partitions are > scanned, and we examine the query to determine which ones must be > scanned. > ​There is an element of logic that says "by default, no partitions are scanned" is not a

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, May 10, 2018 at 10:13 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, May 10, 2018 at 12:58 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > David G. Johnston wrote: > >> As a user I don't really need to know which model is impl

Re: [HACKERS] Surjective functional indexes

On Fri, May 11, 2018 at 4:58 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > Sorry, may be I do not completely understand you. > So whats happed before this patch: > > - On update postgres compares old and new values of all changed attributes > to determine whether them are

Re: [HACKERS] Surjective functional indexes

On Thursday, February 1, 2018, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > Old + New for check = 2 >> plus calculate again in index = 3 >> > > Yes, we have to calculate the value of index expression for original and > updated version of the record. If them are equal, then it is

Re: Fix for FETCH FIRST syntax problems

On Sun, May 20, 2018 at 1:13 PM, Peter Geoghegan wrote: > There have been > cases where we chose to not back-patch an unambiguous bug fix even > though it was clear that incorrect user-visible behavior remained. > ​The risk here is significantly reduced since the existing

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote: > Andrew Gierth writes: > > I'll fix the docs accordingly. I'm referring specifically to this bit: > > https://www.postgresql.org/docs/current/static/functions- >

Re: Allow COPY's 'text' format to output a header

On Tuesday, May 15, 2018, Tom Lane wrote: > > > AFAICS, Daniel's just reacting to the basic idea of a header line. > I agree that by itself that's not worth much. However, if we added > your proposed option to insist that the column names match during COPY > IN, I think that

Re: Fix for FETCH FIRST syntax problems

On Tue, May 22, 2018 at 5:59 AM, Robert Haas wrote: > If we start routinely > back-patching things that fall into that category, we will certainly > manage to destabilize older releases on a regular basis. > Just because something is bad if done in excess doesn't mean

Re: Timetz comparison

On Fri, May 25, 2018 at 3:33 PM, Tom Lane wrote: > Alexey Bashtanov writes: > > Comparison of timetz values looks a bit weird to me, as > > '22:00+02'::timetz > '21:00+01'::timetz. > > Perhaps, but I don't think there's a reasonable case for considering >

Re: computing z-scores

On Thursday, May 24, 2018, David G. Johnston <david.g.johns...@gmail.com> wrote: > On Thu, May 24, 2018 at 8:15 AM, Martin Mueller < > martinmuel...@northwestern.edu> wrote: > >> You construct a z-score for a set of values by subtracting the average >> from

Re: computing z-scores

On Thu, May 24, 2018 at 8:15 AM, Martin Mueller < martinmuel...@northwestern.edu> wrote: > You construct a z-score for a set of values by subtracting the average > from the value and dividing the result by the standard deviation. I know > how to do this in a two-step procedure. First, I compute

Re: Postgres 11 release notes

On Fri, May 11, 2018 at 8:08 AM, Bruce Momjian wrote: > I have committed the first draft of the Postgres 11 release notes. I > will add more markup soon. You can view the most current version here: > > http://momjian.us/pgsql_docs/release-11.html ​Some thoughts:​ ​As a major ​item:

Re: Bug in either collation docs or code

On Fri, Jun 8, 2018 at 9:24 AM, Melanie Plageman wrote: > It seems like this would not allow the function/operator to decide if it > cares about a determinate collation during execution, since it would > already have errored out during planning. > In the case where the function/operator doesn't

Re: Bug in either collation docs or code

On Fri, Jun 8, 2018 at 9:12 AM, Melanie Plageman wrote: > I tried inserting data and did not get an error: > > CREATE TABLE test1 ( > a text COLLATE "de_DE", > b text COLLATE "es_ES" > ); > > INSERT INTO test1 VALUES('b','b'), ('c','c'), ('g','g'), ('h','h'); > SELECT a < (select 'foo'

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On Mon, Jun 18, 2018 at 9:59 AM, Alvaro Herrera wrote: > > alvherre=# select tgname, tgrelid::regclass, tgisinternal from pg_trigger; > tgname │ tgrelid │ tgisinternal > ┼─┼── > trig_p │ parent │ f > trig_p │ child │ t > trig_c │ child │ f > (3 filas) > > So

Re: Bug in either collation docs or code

On Thu, Jun 7, 2018 at 4:37 PM, Melanie Plageman wrote: > CREATE TABLE test1 ( > a text COLLATE "de_DE", > b text COLLATE "es_ES", > ... > ); > > My thought was to add the following example: > > SELECT a < (select 'foo' COLLATE "fr_FR") FROM test1; > > I thought this would error out

Re: Fast default stuff versus pg_upgrade

On Tue, Jun 19, 2018 at 9:37 AM, Tom Lane wrote: > The problem here is that that function does not exist in 11beta1. > Since adding the "incoming" function is certainly going to require > initdb, we have to be able to dump from the server as it now stands, > or we'll be cutting existing beta

Re: csv format for psql

On Sunday, June 3, 2018, Pavel Stehule wrote: > > > \pset fieldsep ; > \pset format csv > > I don't like when one command overwrite settings of some other command. We > can introduce some similar like GUC where default values from configure > file can be overwritten by custom setting for session.

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On Mon, Jun 4, 2018 at 2:40 PM, Tom Lane wrote: > > I think, in general, that we should try to pick semantics that make a > > partitioned table behave like an unpartitioned table, provided that > > all triggers are defined on the partitioned table itself. > > Well, then we lose the property

libpq compression

On Wednesday, June 6, 2018, Peter Eisentraut wrote: > On 6/6/18 13:20, Konstantin Knizhnik wrote: > > Well, psql really allows to specify complete connection string with -d > > options (although it is not mentioned in help). > > But still I think that it is inconvenient to require user to write

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > > My note is related to @b. I understand to the motivation, but I am not > sure if it is good idea. Tables and views shares one namespace. > But the command say "drop table" and so it must only be concerned with that subset of the namespace when

Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > 2018-06-26 17:23 GMT+02:00 Peter Moser : > >> Hi, >> I want to delete a table X, that may not exist, hence I execute >> >> DROP TABLE IF EXISTS X; >> >> However, if X is a view, I get an error >> >> ERROR: "X" is not a table >> >

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tue, Jun 26, 2018 at 10:06 AM, Tom Lane wrote: > Pavel Stehule writes: > > 2018-06-26 18:22 GMT+02:00 David G. Johnston >: > >>> So I am not sure, if proposed change is practical because views and > >>> tables shares same namespace and current behav

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > > Just I don't see this proposal as clean win. More it is not limited only > this case. It should be consistent with DROP INDEX, SEQUENCE, ... > Yes, they are likely all broken in the same way and whomever agrees with the "it's bugged"

Re: automatic restore point

On Mon, Jun 25, 2018 at 6:17 PM, Yotsunaga, Naoki < yotsunaga.na...@jp.fujitsu.com> wrote: > ​​ > So what do you think about it? Do you think is it useful? > ​The cost/benefit ratio seems low...​ Also, when recovering with the current specification, tables other than the > returned table also

Re: Postgres 10.4 crashing when using PLV8

On Wed, Jun 20, 2018 at 12:46 PM, Mukesh Chhatani wrote: > I am trying to use the PLV8 via function and while using the function > created via PLV8 in one of the create materialized view, postgres crashes, > attached is the log file with DEBUG5 turned on. > ​These are not the correct place to

Re: Name of main process differs between servers (postmaster vs postgres)

On Tue, Jun 26, 2018 at 2:51 PM, Jonathan Lemig wrote: > From what I can tell, things are running fine on both servers, I guess I > just don't like there is a difference/inconsistency. Can anyone please > explain this? > > ​Best guess, one of the servers has upgrades from previous versions

Re: power() function in Windows: "value out of range: underflow"

On Tue, May 1, 2018 at 12:08 PM, Robert Haas wrote: > > > But I don't think > > we should discount the existence of the former category. Deploying > > to production on an older release of $system than you develop on > > is hardly an unusual scenario. > > That's probably

Re: Should we add GUCs to allow partition pruning to be disabled?

On Wed, May 2, 2018 at 1:07 AM, Amit Langote wrote: > Hi David. > > On 2018/05/02 8:18, David Rowley wrote: > > On 1 May 2018 at 21:44, Amit Langote > wrote: > > > > I re-read the patch and it still looks fine to me. I'm sure it

Re: Should we add GUCs to allow partition pruning to be disabled?

On Wed, May 2, 2018 at 4:06 PM, David Rowley wrote: > On 1 May 2018 at 21:44, Amit Langote > wrote: > > About the patch in general, it seems like the newly added documentation > > talks about "Partition Pruning" as something that

Should we add GUCs to allow partition pruning to be disabled?

On Wednesday, May 2, 2018, Alvaro Herrera wrote: > Robert Haas wrote: > > On Wed, May 2, 2018 at 9:28 AM, Alvaro Herrera > wrote: > > > I admit I am more concerned about the possibility of bugs than I am > > > about providing a

Re: Usage of pg_waldump

On Tue, May 1, 2018 at 9:26 AM, Andres Freund wrote: > Hi, > > On 2018-05-01 16:41:04 +0900, Dang Minh Huong wrote: > > The syntax is known as, > > > > pg_waldump [OPTION]... [STARTSEG [ENDSEG]] > > > > Mean that, it could work with no arguments. > > But the "no arguments

Re: TODO list (was Re: Contributing with code)

On Sun, Dec 31, 2017 at 11:42 AM, Tom Lane wrote: > Robert Haas writes: > > Also, let's delete the TODO list. People keep using it as a source of > > project ideas, and that's bad. > > If we're not going to maintain/curate it properly, I agree it's

Re: The first function call

On Thu, Jan 11, 2018 at 8:52 AM, Diego Silva e Silva wrote: > Hello, > > The first function call is 10 times slower than the other calls in the > same session. Is it possible to shorten this long time on the first call? > For example. Call my function for once, this call

Re: Is there a "right" way to test if a database is empty?

On Wed, Jan 17, 2018 at 9:10 AM, Graham Leggett wrote: > > db=# select count(s.nspname) from pg_class c join pg_namespace s on s.oid > = c.relnamespace where s.nspname in ('public'); > count > --- > 0 > (1 row) > > It is based on the idea that the database is not

Re: Is there a "right" way to test if a database is empty?

On Wed, Jan 17, 2018 at 9:39 AM, Graham Leggett wrote: > Would it be true to say that if this query returned more than zero rows > the database is not empty? > > db=# select distinct s.nspname from pg_class c join pg_namespace s on > s.oid = c.relnamespace where s.nspname not

Further cleanup of pg_dump/pg_restore item selection code

On Wednesday, January 24, 2018, Tom Lane wrote: > and it has a bunch of strange > behaviors that can really only be characterized as bugs. An example is > that > > pg_dump --create -t sometable somedb > > pg_dump -t: "The -n and -N switches have no effect when -t is

Re: Further cleanup of pg_dump/pg_restore item selection code

On Wednesday, January 24, 2018, Tom Lane wrote: > > I think you might be missing one of the main points here, which is > that --create is specified as causing both a CREATE DATABASE and a > reconnect to that database. > I missed the implication though I read and even thought

CONSTANT/NOT NULL/initializer properties for plpgsql record variables

On Thursday, January 25, 2018, Tom Lane wrote: > > The documentation currently says > > The CONSTANT option prevents the variable from being assigned to > after initialization, so that its value will remain constant for > the duration of the block. >

Re: Further cleanup of pg_dump/pg_restore item selection code

On Wednesday, January 24, 2018, Tom Lane wrote: > > > This does not go all the way towards making pg_restore's item selection > switches dump subsidiary objects the same as pg_dump would, because > pg_restore doesn't really have enough info to deal with indexes and > table

Re: Add RANGE with values and exclusions clauses to the Window Functions

On Fri, Feb 2, 2018 at 9:26 AM, Oliver Ford <ojf...@gmail.com> wrote: > On Thu, Feb 1, 2018 at 1:46 AM, David G. Johnston > <david.g.johns...@gmail.com> wrote: > > > The three callers of WinGetFuncArgInFrame don't use the isout argument; > they > > probably ne

Re: Add RANGE with values and exclusions clauses to the Window Functions

On Wed, Jan 31, 2018 at 5:06 PM, Tom Lane wrote: > We could imagine reimplementing WinGetFuncArgInFrame to fix this, but > aside from the sheer inefficiency of simple fixes, I'm not very clear > what seeking relative to WINDOW_SEEK_CURRENT should mean when the current > row

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On Mon, Jan 29, 2018 at 2:55 AM, David Rowley wrote: > On 28 January 2018 at 12:00, Tomas Vondra > wrote: > > On 01/27/2018 10:45 PM, Tom Lane wrote: > >> David Rowley writes: > >>> I'd offer to put it

Re: Better Upgrades

On Mon, Feb 5, 2018 at 5:09 PM, David Fetter wrote: > > The proposal has blockers: > > - We don't actually have logical decoding for DDL, although I'm given > to understand that Álvaro Herrera has done some yeoman follow-up > work on Dimitri Fontaine's PoC patches. > - We

Re: git instructions

On Tue, Feb 6, 2018 at 1:46 PM, Stefan Kaltenbrunner < ste...@kaltenbrunner.cc> wrote: > > > > > Yes, this used to be the case, and is the reason behind the original > > recommendation. It's what they call the "dumb HTTP protocol" in the > > docs. This is not the case when you use

Re: CALL stmt, ERROR: unrecognized node type: 113 bug

On Fri, Feb 9, 2018 at 7:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "David G. Johnston" <david.g.johns...@gmail.com> writes: > > On Fri, Feb 9, 2018 at 6:23 AM, Michael Paquier <mich...@paquier.xyz> > wrote: > >> On Fri, Feb 09, 2018 at 12:0

Re: Is there a cache consistent interface to tables ?

On Fri, Feb 9, 2018 at 12:56 AM, Garym wrote: > Hi, > This is an odd request for help. I'm looking to expose an interface so an > external app can insert to a table while maintaining cache consistency and > inserts be promoted via wal. > ​I don't understand what that all means

Re: CALL stmt, ERROR: unrecognized node type: 113 bug

On Fri, Feb 9, 2018 at 6:23 AM, Michael Paquier wrote: > On Fri, Feb 09, 2018 at 12:02:57PM +0100, Pavel Stehule wrote: > > 2018-02-09 7:56 GMT+01:00 Michael Paquier : > > > The second problem involves a cache lookup failure for a type when > > > trying

Re: BUG #15044: materialized views incompatibility with logical replication in postgres 10

Adding -hackers to this in the interest of getting it committed by Monday's wrap-up. https://www.postgresql.org/message-id/6e375316-91a4-7825-ef8b-9b8915ab6980%402ndquadrant.com David J. On Sat, Feb 17, 2018 at 8:43 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2/5/18

Re: pgsql: Allow UNIQUE indexes on partitioned tables

On Tue, Feb 20, 2018 at 8:36 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Many thanks for reading through it! > > David G. Johnston wrote: > > I found the following change to be confusing. > [...] > > I was expecting the doc for ADD CONSTRAINT USING IN

Re: pgsql: Allow UNIQUE indexes on partitioned tables

I found the following change to be confusing. /doc/src/sgml/ref/alter_table.sgml + +Additional restrictions apply when unique indexes are applied to +partitioned tables; see . + That paragraph appears in the section covering "ALTER TABLE name ADD

Re: Cost Model

On Wed, Dec 20, 2017 at 12:26 PM, neto brpr wrote: > > About what you said, that some settings can be configured by Tablespace? > I have already seen this in IBM DB2, but in Postgresql as far as I know, > for example the Random_page_cost and Seq_page_cost parameters are >

Re: Cost Model

On Wed, Dec 20, 2017 at 11:26 AM, neto brpr wrote: > Dear David > I have read documentation that you send, but it has only sequential page > cost and random page cost parameters. What I need, would be a model of > custo for Differentiate Read/Write (sequential and random),

Re: Usability fail with psql's \dp command

On Tue, Jul 31, 2018 at 7:24 AM, Robert Haas wrote: > On Sat, Jul 28, 2018 at 4:36 PM, David Fetter wrote: > > Please find attached a patch to fix this. Would this be a > > back-patchable bug? > > In my view, this is not a bug fix, but an improvement, and therefore > should not be

Re: [HACKERS] Bug in to_timestamp().

On Thu, Aug 16, 2018 at 3:53 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Hi, David! > > You can notice that: > > 1) We identified downside of changes in to_timestamp() function and > documented them [1]. > 2) We found 4 more differences between between patches behavior and >

Re: Typo in doc or wrong EXCLUDE implementation

On Thu, Aug 9, 2018 at 12:31 PM, Tom Lane wrote: > I think the OP is reading "equivalent" literally, as meaning that > an EXCLUDE with operators that act like equality is treated as being > the same as UNIQUE for *every* purpose. We're not going there, IMO, > so probably we need to tweak the

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Saturday, August 18, 2018, Jonathan S. Katz wrote: > > It’s cosmetic, but it’s a cosmetic bug: it incorrectly tells the user that > they > must be the owner of the “relational” when in reality it’s the > materialized view. > Materialized views are a type of relation so it is not wrong, just

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Saturday, August 18, 2018, Dave Cramer wrote: > > I was referring to: > > "Materialized views are a type of relation so it is not wrong, just one > of many instances where we generalize to "relation" based in implementation > details ins team of being explicit about which type of relation is

Re: Getting NOT NULL constraint from pg_attribute

On Monday, August 20, 2018, Wu Ivy wrote: > > Thanks for the quick respond. > Why are SELECT query never marked nullable? For nullable columns, when I > call SPI_getvalue(), the result (in char*) is NULL. I don’t think I’m too > clear on the definition of *attnotnull*. Can you give me a example

Re: Stored procedures and out parameters

On Tuesday, August 28, 2018, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > First of all, what do you want to do with the function return value > when you use CALL? > Place it in the result set. > And would you expect a function that is invoked via CALL to have a > non-atomic

Re: has_table_privilege for a table in unprivileged schema causes an error

On Sat, Aug 25, 2018 at 8:29 PM, Tom Lane wrote: > There's a backwards-compatibility argument for not changing this behavior, > sure, but I don't buy the other arguments you made here. And I don't > think there's all that much to the backwards-compatibility argument, > considering that the

Re: Stored procedures and out parameters

On Wed, Aug 22, 2018 at 9:39 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 16/08/2018 19:54, Shay Rojansky wrote: > > I don't think there's anything really Microsoft-specific about any of > > this (except maybe in the history) - just like JDBC and psycopg, there's > >

Re: One transaction and several processes

On Wed, Jul 18, 2018 at 8:31 AM, Valery Kuzmin wrote: > Hi, > > Can multiple processes participate in a single transaction's execution? > I need to do the following actions sequence: > 1. Calling service begins transaction. At this step transaction > manager generate new XID. > 2. Calling

Re: Missing pg_control crashes postmaster

On Mon, Jul 23, 2018 at 12:31 PM, Brian Faherty < anothergenericu...@gmail.com> wrote: > There does not really seem to be a need for this behavior as all the > information postgres needs is in memory at this point. I propose with > a patch to just recreate pg_control on updates if it does not

Re: Stored procedures and out parameters

On Tue, Jul 24, 2018 at 11:31 AM, Daniel Verite wrote: > David G. Johnston wrote: > > > > 2. A stored procedure can decide dynamically of > > > the structure of the resultset(s) it returns, > > > and the caller will discover it as t

Re: [HACKERS] Bug in to_timestamp().

O) more clear. > > However, in this thread other opinions were expressed. In > particular, David G. Johnston expressed opinion that we shouldn't change > behavior of existing functions, alternatively we could introduce new > functions with new behavior. However, I see David doesn't pa

Re: psql's \d versus included-index-column feature

On Thursday, July 19, 2018, Tom Lane wrote: > > > Given that the documentation refers to included columns as "non-key > > columns", it seems natural to me to name the \d output column "Key?" and > > use "yes/no" as the values. > > WFM, anyone want to argue against? > Works for me as well.

Re: psql's \d versus included-index-column feature

On Wed, Jul 18, 2018 at 12:55 PM, Tom Lane wrote: > > regression=# \d tbl_include_reg_idx > Index "public.tbl_include_reg_idx" > Column | Type | Key | Definition > +-+-- > c1 | integer | t | c1 > c2 | integer | t | c2 > c3 | integer | f |

Re: Stored procedures and out parameters

On Tue, Jul 24, 2018 at 6:58 AM, Daniel Verite wrote: > Vladimir Sitnikov wrote: > > > There's no notion if the called object is a procedure or function. > > Note: PostgreSQL can have a function that `returns void`, and it is hard > to > > tell if {call test()} refers to a function or

Re: Stored procedures and out parameters

On Mon, Jul 23, 2018 at 12:07 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > 2) Just a side note: `CALL my_proc()` is not suitable for functions. That > looks weird. > Is the client expected to lookup system catalogs in order to tell if > `my_proc` is procedure or function and use

Re: [HACKERS] Bug in to_timestamp().

On Mon, Sep 3, 2018 at 2:30 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > The current version of patch doesn't really distinguish spaces and > delimiters in format string in non-FX mode. So, spaces and delimiters > are forming single group. For me Oracle behavior is ridiculous at

Re: Add --include-table-data-where option to pg_dump, to export only a subset of table data

On Thu, Sep 6, 2018 at 8:40 AM, Jeremy Finzel wrote: > Why not simply use \copy (select * from largetable where created_at >= >> '2018-05-01') to stdout? That is what I’ve always done when I need >> something like this and have not found it particularly bothersome but >> rather quite powerful.

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Wednesday, July 4, 2018, Tom Lane wrote: > > Also, based on other messages, it seems like what the OP wants is > to be sure that "CREATE TABLE X" will succeed afterwards, so that > failing to get rid of view X will not do what he needs. > I read and agree that what should be possible, absent

Re: Transition relations: correlating OLD TABLE and NEW TABLE

On Friday, July 6, 2018, Brent Kerby wrote: > Of course if the table has a primary key, then this can be used, but I'm > wondering how to handle this in the general case where a primary key might > not exist. > Personally, I would consider the lack of a PK a rare and special case...I'd handle

Re: Transition relations: correlating OLD TABLE and NEW TABLE

On Saturday, July 7, 2018, Brent Kerby wrote: > > Also, there are cases where it may not be desired to have a primary key, > as the index maintenance and constraint checking are not free and not > always necessary. > Btree uniqueness enforcement is worth the price. > I'd be happy to try to

Re: pgsql: Fix parallel index and index-only scans to fall back to serial.

On Fri, Jul 13, 2018 at 12:22 PM, Heikki Linnakangas wrote: > Hi! > > I just bumped into this comment, from commit 09529a70bb5, and I can't make > sense of it: > > + /* >> +* We reach here if the index only scan is not parallel, >> or if we're >> +*

Re: cannot restore schema with is not distinct from on hstore since PG 9.6.8

On Fri, Jul 13, 2018 at 1:54 PM, Tom Lane wrote: > So this is all pretty messy, but on the bright side, fixing it would allow > cleaning up some ancient squishy coding in ruleutils.c. It wouldn't be > controversial as just a v12 addition, perhaps ... but do we have a choice > about

Re: documentation is now XML

On Tuesday, January 23, 2018, Bruce Momjian wrote: > On Tue, Jan 23, 2018 at 10:22:53PM -0500, Tom Lane wrote: > (a) it's got hard > > limits we're approaching, > All agreed, but what alternatives are being developed? > > I seem to recall a proposal a while back to gain

[HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

On Monday, January 22, 2018, Stephen Frost wrote: > > In the end, I feel like this patch has actually been through the ringer > and back because it was brought up in the context of solving a problem > that we'd all like to fix in a better way. Had it been simply dropped > on

For consideration - clarification of multi-dimensional arrays in our docs.

Hey all! This doesn't come up that often but enough that it seems hammering home that multi-dimension <> array-of-array seems warranted. The first and last chuck cover definition and iteration respectively. The second chuck removes the mention of "subarray" since that's what we don't want

Re: csv format for psql

On Fri, Mar 9, 2018 at 12:42 PM, Daniel Verite wrote: > I wrote: > > > recordsep in the unaligned mode doesn't play the role of a line ending > > because the last line is not finished by recordsep. According to the > source > >code, this is intended, see

Re: CALL optional in PL/pgSQL

On Wednesday, February 28, 2018, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > > I seem to recall that there were past discussions about this, with > respect to the PERFORM command, but I couldn't find them anymore. > I'm thinking you are thinking of this one.

Comments on old bug report in light of CVE-2018-1058

Hackers, By happen-stance I recently came across an old bug report that I responded to, #13651 (circa 2015-09), and reading the commentary for CVE-2018-1058 made me think about it in a different light. While no one added to my responses back then I'm thinking it would be worthwhile if one or

Re: planner bug regarding lateral and subquery?

On Tuesday, March 13, 2018, Tatsuro Yamada wrote: > Hi Hackers, > > I found a bug, maybe. > If it is able to get an explain command result from below query > successfully, > I think that it means the query is executable. > There is a difference between executable,

Re: csv format for psql

On Fri, Mar 9, 2018 at 3:18 PM, Daniel Verite wrote: > I think that the point of recordsep in unaligned mode is you can set it > to something that never appears in the data, especially when embedded > newlines might be in the data. In CSV this is solved differently so >

Re: Fixes for missing schema qualifications

On Tue, Mar 13, 2018 at 5:11 PM, Tatsuo Ishii wrote: > >>> +"select pg_catalog.count(*) " > >>> +"from pg_catalog.pg_namespace > where nspname = '%s'", > >> > >> This qualifies some functions, but it

Re: Fixes for missing schema qualifications

On Tue, Mar 13, 2018 at 5:26 PM, Tatsuo Ishii wrote: > Next question is, should we update the manual? There are bunch of > places where example queries are shown without schema qualifications. > > I hope that isn't deemed necessary. David J.

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Wednesday, April 4, 2018, Amit Kapila wrote: > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > > > > > Questions: > > > > - I'm not perfectly happy with > > "tuple to be locked was already moved to another partition due to > concurrent

Native partitioning tablespace inheritance

On Thursday, April 12, 2018, Robert Haas wrote: > On Thu, Apr 12, 2018 at 2:40 PM, Jonathan S. Katz > wrote: > > If there are no strong objections I am going to add this to the “Older > Bugs” > > section of Open Items in a little bit. > > I

  1   2   3   4   5   6   7   8   9   10   >