Re: [HACKERS] review: CHECK FUNCTION statement

Pavel Stehule wrote: there is merged patch Works fine, except that there are still missing const qualifiers in copyfuncs.c and equalfuncs.c that lead to compiler warnings. One thing I forgot to mention: I thought there was a consensus to add a WITH() or OPTIONS() clause to pass options to the

Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

Tom Lane wrote: Shigeru Hanada shigeru.han...@gmail.com writes: (2011/12/12 22:59), Robert Haas wrote: ... I feel like we might need a system here that allows for more explicit user control about what to push down vs. not, rather than assuming we'll be able to figure it out behind the scenes.

Re: [HACKERS] review: CHECK FUNCTION statement

Pavel Stehule wrote: One thing I forgot to mention: I thought there was a consensus to add a WITH() or OPTIONS() clause to pass options to the checker function: http://archives.postgresql.org/message-id/12568.1322669...@sss.pgh.pa.us I think this should be there so that the API does not have

Re: [HACKERS] review: CHECK FUNCTION statement

Pavel Stehule wrote: changes: * fixed warnings * support for options - actually only two options are supported - quite and fatal_errors these options are +/- useful - main reason for their existence is testing of support of options - processing on CHECK ... stmt side and processing on

Re: [HACKERS] review: CHECK FUNCTION statement

Pavel Stehule wrote: so removed quite option and removed multiple check regression tests also - there is missing explicit order of function checking, so regress tests can fail :( There seems to be a problem with the SET clause of CREATE FUNCTION: ftest=# CREATE OR REPLACE FUNCTION a(integer)

Re: [HACKERS] review: CHECK FUNCTION statement

Pavel Stehule wrote: one small update - better emulation of environment for security definer functions Patch applies and compiles fine, core functionality works fine. I found a little bug: In backend/commands/functioncmds.c, function CheckFunction(CheckFunctionStmt *stmt), while you perform

[HACKERS] Fix for bug in ldapServiceLookup in libpq

I have found a small but annoying bug in libpq where connection parameters are resolved via LDAP. There is a write past the end of a malloc'ed string which causes memory corruption. The code and the bug are originally by me :^( The attached patch fixes the problem in HEAD. This should be

Re: [HACKERS] Fix for bug in ldapServiceLookup in libpq

Tom Lane wrote: I have found a small but annoying bug in libpq where connection parameters are resolved via LDAP. Hmm ... that's a bug all right, but why have the null-termination inside the loop at all? Seems like it should look like for (p = result, i = 0; values[i] != NULL; ++i)

[HACKERS] Uninitialized SSL values? (was: Fix for bug in ldapServiceLookup in libpq)

I wrote: I have found a small but annoying bug in libpq where connection parameters are resolved via LDAP. I have attached a new version of the patch that should address all known problems. FWIW, I ran valgrind on psql establishing an SSL connection, and I found some messages like this:

Re: [HACKERS] Fix for bug in ldapServiceLookup in libpq

Tom Lane wrote: You missed one return where the string needed to be freed. I've applied this patch with that fix and a couple of cosmetic changes. Thanks for the report and patch! Thanks for the work and the keen eye! Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list

[HACKERS] Review: Display number of changed rows since last analyze

This is a review of the patch in 5192d7d2.8020...@catalyst.net.nz The patch applies cleanly (with the exception of catversion.h of course), compiles without warnings and passes the regression tests. It contains enough documentation, though I'd prefer Estimated number of rows modified since the

Re: [HACKERS] Frontend/backend protocol improvements proposal (request).

Dmitriy Igrishin wrote: Sent: Thursday, June 20, 2013 5:09 PM To: PostgreSQL Hackers Subject: [HACKERS] Frontend/backend protocol improvements proposal (request). Hackers, While developing a C++ client library for Postgres I felt lack of extra information in command tags in the

[HACKERS] Possible bug in CASE evaluation

I want to draw attention to this thread on -general: camq5dgq4sujpbht2-9xlapasvknul2-bb0cpyci2fp+pfsf...@mail.gmail.com Would you concur that this is a bug? The fine manual says about CASE: If the condition's result is true, the value of the CASE expression is the result that follows the

Re: [HACKERS] Possible bug in CASE evaluation

Andres Freund wrote: On 2013-06-21 08:16:22 +, Albe Laurenz wrote: I want to draw attention to this thread on -general: camq5dgq4sujpbht2-9xlapasvknul2-bb0cpyci2fp+pfsf...@mail.gmail.com There's also a bug reported for it: #8237: e1uovmc-0007ft...@wrigleys.postgresql.org Would you

Re: [HACKERS] [GENERAL] Floating point error

Abhijit Menon-Sen wrote: Sorry to nitpick, but I don't like that either, on the grounds that if I had been in Tom Duffey's place, this addition to the docs wouldn't help me to understand and resolve the problem. I'm not entirely convinced that any brief mention of extra_float_digits would

Re: [HACKERS] Possible bug in CASE evaluation

Noah Misch wrote: If fixing the behaviour is undesirable, at least the documentation should be fixed. A brief documentation mention sounds fine. Perhaps add a paragraph on constant folding in general and reference that from the CASE page. How about the attached? Yours, Laurenz Albe

Re: [HACKERS] Kudos for Reviewers -- straw poll

Dean Rasheed wrote: How should reviewers get credited in the release notes? a) not at all b) in a single block titled Reviewers for this version at the bottom. c) on the patch they reviewed, for each patch b) Unless they contribute enough to the patch to be considered a co-author.

Re: [HACKERS] Review: Display number of changed rows since last analyze

Magnus Hagander wrote: On Mon, Jun 17, 2013 at 1:49 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote: This is a review of the patch in 5192d7d2.8020...@catalyst.net.nz The patch applies cleanly (with the exception of catversion.h of course), compiles without warnings and passes the regression

Re: [HACKERS] Review: Display number of changed rows since last analyze

Magnus Hagander wrote: On Mon, Jun 17, 2013 at 1:49 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote: I think that the column name is ok as it is, even if it is a bit long - I cannot come up with a more succinct idea. Perhaps n_changed_since_analyze could be shortened to n_mod_since_analyze

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Magnus Hagander wrote: On Tue, Feb 5, 2013 at 10:39 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote: I found a small bug in the implementation of LDAP connection parameter lookup. [...] As coded now, the timeout won't work - if the LDAP server is down, ldap_simple_bind will wait

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Peter Eisentraut wrote: Btw., I just checked the source code of Apache, PHP, and PAM, and they are all unconditionally building with LDAP_DEPRECATED. So maybe there is no hurry about this. I don't think that the old API functions will go away until there is a new standard for the LDAP C API,

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Magnus Hagander wrote: In that case, doesn't this patch break Windows? We no longer do the anonymous bind on Windows, since it's now in the #ifdef HAVE_LIBLDAP. Don't we need to keep the ldap_simple_bind() call in the Windows case, or break it up so the call to ldap_sasl_bind_s() is moved

Re: [HACKERS] potential bug in error message in with clause

Szymon Guz wrote: today on IRC there was a strange problem shown. The small working example looks like this: x=# with x as (insert into a(t) values('1') returning *) select * from x; t --- 1 (1 row) x=# with x (insert into a(t) values('1') returning *) select * from x; ERROR:

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Magnus Hagander wrote: The patch should still be good, but if we keep the deprecated OpenLDAP API, it might be more consistent to use ldap_simple_bind_s instead of ldap_sasl_bind_s. If you agree, I'll change that. Sorry, you got this one in just as my vacation started. Yes, I agree with

Re: [HACKERS] [GENERAL] problem in installation of postgresql-jdbc

Vivek Singh Raghuwanshi wrote: I am trying to install postgresql-jdbc but facing java error. It would be helpful to know which error you are facing. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] REVIEW: Allow formatting in log_line_prefix

This is a review for patch caaphdvpagtypzb2kwa0mmtksayg9+vashyjmjfatngxr1ad...@mail.gmail.com The patch is readable, applies fine and builds without warnings. It contains sufficient documentation. It works as it should, no crashes or errors. It is well written, in fact it improves the

Re: [HACKERS] FW: REVIEW: Allow formatting in log_line_prefix

David Rowley wrote: I moved the source around and I've patched against it again. New patch attached. Thank you, marked as ready for committer. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Abhijit Menon-Sen wrote: I read through the patch, and it looks sensible. Thanks for the thorough review! I would have preferred the ldap_simple_bind_s() call in the HAVE_LIBLDAP branch to not be inside an else {} (the if block above returns if there is an error anyway), but that's a minor

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Peter Eisentraut wrote: [good suggestions for improvement] I'll send an updated patch on Monday. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Peter Eisentraut wrote: --- 3511,3534 } /* ! * Perform an explicit anonymous bind. ! * This is not necessary in principle, but we want to set a timeout ! * of PGLDAP_TIMEOUT seconds and return 2 if the connection fails. ! * Unfortunately there is no standard

Re: [HACKERS] Getting Tuples list from an index

Naman wrote: I have an 3 indexes on a relation t2(A,B,C) index1 , index2 ,index3 What i need is if i know the indexname (say index1) then is their any programmatic way by which i can get the list of tuples which comes under the index specified( i.e index1) Do you need anything that

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

Arul Shaji Arulappan wrote: Attached is a patch that implements the first set of changes discussed in this thread originally. They are: (i) Implements NCHAR/NVARCHAR as distinct data types, not as synonyms so that: - psql \d can display the user-specified data types. -

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

MauMau wrote: From: Albe Laurenz laurenz.a...@wien.gv.at If I understood the discussion correctly the use case is that there are advantages to having a database encoding different from UTF-8, but you'd still want sume UTF-8 columns. Wouldn't it be a better design to allow specifying

[HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

I have a question concerning the Foreign Data Wrapper API: I find no mention of this in the documentation, but I remember that you can only add a resjunk column that matches an existing attribute of the foreign table and not one with an arbitrary name or definition. Ist that right? Yours,

Re: [HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

Tom Lane wrote: Albe Laurenz laurenz.a...@wien.gv.at writes: I have a question concerning the Foreign Data Wrapper API: I find no mention of this in the documentation, but I remember that you can only add a resjunk column that matches an existing attribute of the foreign table and not one

Re: [HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

Tom Lane wrote: Albe Laurenz laurenz.a...@wien.gv.at writes: What I would like to do is add a custom resjunk column (e.g. a bytea) in AddForeignUpdateTargets that carries a row identifier from the scan state to the modify state. Would that be possible? Can I have anything else than a Var

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

MauMau wrote: Let me repeat myself: I think the biggest and immediate issue is that PostgreSQL does not support national character types at least officially. Officially means the description in the manual. So I don't have strong objection against the current (hidden) implementation of nchar

Re: [HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

Tomas Vondra wrote: have you found a way to pass data types other than TID as a resjunk column? I'm trying to solve almost the same thing (pass INT8 instead of TID), but I got stuck. Adding a custom Var with INT8OID instead of TIDOID seems to work fine, but I've found no way to populate

Re: [HACKERS] writable FDWs / update targets confusion

Tomas Vondra wrote: I'm working on adding write support to one of my FDWs. Adding INSERT went pretty fine, but when adding DELETE/UPDATE I got really confused about how the update targets are supposed to work. My understanding of how it's supposed to work is this: (1)

Re: [HACKERS] writable FDWs / update targets confusion

Tom Lane wrote: Tom, could you show us a rope if there is one? What is it you actually need to fetch? IIRC, the idea was that most FDWs would do the equivalent of fetching the primary-key columns to use in an update. If that's what you need, then AddForeignUpdateTargets should identify

Re: [HACKERS] Proposed feature: Selective Foreign Keys

Tom Dunstan wrote: The Problem - One case that traditional SQL doesn't handle very well is when you have a child entity which can be attached to a number of different parent entities. Examples might be comments, tags or file attachments - we might have 20 different

Re: [HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

Ian Lawrence Barwick wrote: 2013/11/8 Tom Lane t...@sss.pgh.pa.us: [ thinks for awhile... ] Hm. In principle you can put any expression you want into the tlist during AddForeignUpdateTargets. However, if it's not a Var then the planner won't understand that it's something that needs to be

Re: [HACKERS] ANALYZE sampling is too good

Greg Stark wrote: It's also applicable for the other stats; histogram buckets constructed from a 5% sample are more likely to be accurate than those constructed from a 0.1% sample. Same with nullfrac. The degree of improved accuracy, would, of course, require some math to determine. This

Re: [HACKERS] ANALYZE sampling is too good

Greg Stark wrote: Doesn't all that assume a normally distributed random variable? I don't think so because of the law of large numbers. If you have a large population and sample it the sample behaves like a normal distribution when if the distribution of the population isn't. Statistics

Re: [HACKERS] Like operator for name type

Mohsen SM wrote: I don't find where of code run the like operation for name Type. can you tell me where compare Like clues with one column of name type ? I don't find function for this operation in /src/backend/utils/adt/name.c when I was in debugging mode and get break point on all

Re: [HACKERS] Compiling extensions on Windows

Craig Ringer wrote: Out of personal interest (in pain and suffering) I was recently looking into how to compile extensions out-of-tree on Windows using Visual Studio (i.e. no PGXS). It looks like the conventional answer to this is Do a source build of PG, compile your ext in-tree in

Re: [HACKERS] NOT Null constraint on foreign table not working

Rushabh Lathia wrote: I found constraints on foreign table is very useful for the application when the multiple user accessing same remote table using fdw and both user want to enforce different constraint on particular table or different user want to enforce different DEFAULT expression

Re: [HACKERS] Changeset Extraction v7.3

Andreas Karlsson wrote: On 01/28/2014 10:56 PM, Andres Freund wrote: On 2014-01-28 21:48:09 +, Thom Brown wrote: On 28 January 2014 21:37, Robert Haas robertmh...@gmail.com wrote: On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas robertmh...@gmail.com wrote: The point of Andres's patch set

Re: [HACKERS] PostgreSQL Failback without rebuild

Michael Paquier wrote: On Fri, Feb 7, 2014 at 3:02 PM, James Sewell james.sew...@lisasoft.com wrote: Node A could get ahead even if it has been shut down cleanly BEFORE the promotion? I'd always assumed if I shut down the master the slave would be at the same point after shutdown - is

Re: [HACKERS] [GENERAL] client encoding that psql command sets

[CC'ed -hackers] Tsubasa Sakamoto wrote: Not sure that it makes a difference but the docs say psql looks at LC_CTYPE not LANG for Unix systems. You did not say what OS you are working on though from the examples I am guessing some form of Unix. The LC_CTYPE environment variable was set up

Re: [HACKERS] GSoC proposal

I'm applying for GSoC 2014 with Postgresql and would appreciate your comments on my proposal (attached). I'm looking for technical corrections/comments and your opinions on the project's viability. In particular, if the community has doubts about its usefulness, I would start working on

Re: [HACKERS] The case against multixact GUCs

Josh Berkus wrote: What makes these GUCs worse is that nobody knows how to set them; nobody on this list and nobody in the field. Heck, I doubt 1 in 1000 of our users (or 1 in 10 people on this list) know what a multixact *is*. I won't contend your first statement, but multixacts are

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

Peter Geoghegan wrote: With the addition of LATERAL subqueries, Tom fixed up the mechanism for keeping track of which relations are visible for column references while the FROM clause is being scanned. That allowed errorMissingColumn() to give a more useful error to the one produced by the

Re: [HACKERS] Patch: iff - if

Nicolas Barbier wrote: 2014-04-17 Michael Paquier michael.paqu...@gmail.com: Is there no equivalent in German? For example in French there is ssi. gdw (genau dann, wenn) Sorry, but I as a German native speaker and mathematitian have never encountered this abbreviation. I am familiar with

Re: [HACKERS] [GENERAL] client encoding that psql command sets

Bruce Momjian wrote: I suggest the attached documentation fix. Patch applied and backpatched to 9.3. Thanks. What would PostgreSQL do without Bruce who undertakes the Herculean task of making sure that nothing gets forgotten and slips through the cracks? Thanks! Yours, Laurenz Albe --

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

Jason Petersen wrote: Yes, we obviously want a virtual clock. Focusing on the use of gettimeofday seems silly to me: it was something quick for the prototype. The problem with the clocksweeps is they don’t actually track the progression of “time” within the PostgreSQL system. Would it

Re: [HACKERS] 9.4 Proposal: Initdb creates a single table

Simon Riggs wrote: I propose we add a single table called Postgres when we Initdb CREATE TABLE Postgres (Id Integer, Data Jsonb); COMMENT ON TABLE Postgres IS 'Single table for quick start usage - design your database'; The purpose of this is to make the database immediately usable.

Re: [HACKERS] 9.4 Proposal: Initdb creates a single table

Craig Ringer wrote: Good that you mention that! I have wondered what to do with it. When I first connected to PostgreSQL, I created a sample table, but the senior developer from the other office told me that this is the postgres database and that I shouldn't create any objects there. What

Re: [HACKERS] Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)

Amit Langote wrote: Is the following behavior perceived fix-worthy? -- note the '1's in the outputs postgres=# CREATE TABLE test AS SELECT; SELECT 1 postgres=# insert into test select; INSERT 0 1 Or maybe, it just means 1 'null' row/record and not no row at all? Right, I'd say you end

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

Ronan Dunklau wrote: Since my last proposal didn't get any strong rebuttal, please find attached a more complete version of the IMPORT FOREIGN SCHEMA statement. I tried to follow the SQL-MED specification as closely as possible. This adds discoverability to foreign servers. The structure

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

Michael Paquier wrote: After sleeping on it, I have put my hands on the postgres_fdw portion and came up with a largely simplified flow, resulting in the patch attached. [...] Ronan, what do you think of those patches? I have nothing more to add, and I think that they should be looked by

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Shigeru Hanada wrote: * Naming of new behavior You named this optimization Direct Update, but I'm not sure that this is intuitive enough to express this behavior. I would like to hear opinions of native speakers. How about batch foreign update or batch foreign modification? (Disclaimer: I'm

[HACKERS] Re: [GENERAL] pg_dump behaves differently for different archive formats

Tom Lane wrote on Dec 16, 2013: Albe Laurenz laurenz.a...@wien.gv.at writes: Restoring a plain format dump and a custom format dump of the same database can lead to different results: pg_dump organizes the SQL statements it creates in TOC entries. If a custom format dump is restored

Re: [HACKERS] How to manage shared library lifetime through C functions

Seref Arikan wrote: I hope this is the right group to ask this question; apologies if this should go the general or some other list. I have multiple shared libraries that can be called from C that I'd like to use from a C based postgresql function. These libraries perform some

Re: [HACKERS] How to manage shared library lifetime through C functions

Craig Ringer wrote: On 08/04/2014 06:31 PM, Seref Arikan wrote: Thanks a lot Heikki and Albe. Exactly what I was asking for. Heikki: the libraries are written in languages that have their own runtime and their documentation insists that both init and dispose calls are performed when used from

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Etsuro Fujita wrote: Done. (I've left deparseDirectUpdateSql/deparseDirectDeleteSql as-is, though.) Other changes: * Address the comments from Eitoku-san. * Add regression tests. * Fix a bug, which fails to show the actual row counts in EXPLAIN ANALYZE for UPDATE/DELETE without a

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Etsuro Fujita wrote: Please find attached the updated version of the patch. I gave it a spin and could not find any undesirable behaviour, and the output of EXPLAIN ANALYZE looks like I'd expect. I noticed that you use the list length of fdw_private to check if the UPDATE or DELETE is pushed

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

I wrote: I gave it a spin and could not find any undesirable behaviour, and the output of EXPLAIN ANALYZE looks like I'd expect. I noticed that you use the list length of fdw_private to check if the UPDATE or DELETE is pushed down to the remote server or not. While this works fine, I

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Etsuro Fujita wrote: I agree with you on that point. So, I've updated the patch to have the explicit flag, as you proposed. Attached is the updated version of the patch. In this version, I've also revised code and its comments a bit. Thank you, I have set the patch to Ready for Committer.

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Tom Lane wrote: Stephen Frost sfr...@snowman.net writes: I have to admit that, while I applaud the effort made to have this change only be to postgres_fdw, I'm not sure that having the update/delete happening during the Scan phase and then essentially no-op'ing the

Re: [HACKERS] WIP: multivariate statistics / proof of concept

Tomas Vondra wrote: attached is a WIP patch implementing multivariate statistics. I think that is pretty useful. Oracle has an identical feature called extended statistics. That's probably an entirely different thing, but it would be very nice to have statistics to estimate the correlation

Re: [HACKERS] PostgreSQL Service Name Enhancement - Wildcard support for LDAP/DNS lookup

I have suggested a similar feature before and met with little enthusiasm: http://www.postgresql.org/message-id/d960cb61b694cf459dcfb4b0128514c2f34...@exadv11.host.magwien.gv.at I still think it would be a nice feature and would make pg_service.conf more useful than it is now. Yours, Laurenz Albe

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

David Fetter wrote: On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote: Just out of curiosity, why is Oracle's NUMBER (I assume you are talking about this) so fast? I suspect that what happens is that NUMBER is stored as a native type (int2, int4, int8, int16) that depends on its

Re: [HACKERS] plpgsql plan changes causing failure after repeated invocation

Merlin Moncure wrote: I chased down a problem today where users were reporting sporadic failures in the application. Turns out, the function would work exactly 5 times and then fail; this is on 9.2. I think I understand why this is happening and I'm skeptical it's a bug in postgres, but I

[HACKERS] Unlogged tables can vanish after a crash

I observed an interesting (and I think buggy) behaviour today after one of our clusters crashed due to an out of space condition in the data directory. Five databases in that cluster have each one unlogged table. The log reads as follows: PANIC could not write to file pg_xlog/xlogtemp.1820: No

Re: [HACKERS] Unlogged tables can vanish after a crash

Andres Freund wrote: On 2014-11-19 11:26:56 +, Albe Laurenz wrote: I observed an interesting (and I think buggy) behaviour today after one of our clusters crashed due to an out of space condition in the data directory. Hah, just a couple days I pushed a fix for that ;) http

[HACKERS] Functions used in index definitions shouldn't be changed

Currently it is possible to change the behaviour of a function with CREATE OR REPLACE FUNCTION even if the function is part of an index definition. I think that should be forbidden, because it is very likely to corrupt the index. I expect the objection that this would break valid use cases where

Re: [HACKERS] Functions used in index definitions shouldn't be changed

Tom Lane wrote: Antonin Houska a...@cybertec.at writes: Albe Laurenz laurenz.a...@wien.gv.at wrote: Currently it is possible to change the behaviour of a function with CREATE OR REPLACE FUNCTION even if the function is part of an index definition. I think that should be forbidden, because

Re: [HACKERS] Functions used in index definitions shouldn't be changed

Robert Haas wrote: On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote: I don't think that there is a universally compelling right or wrong to questions like this, it is more a matter of taste. Is it more important to protect the casual DBA from hurting himself

Re: [HACKERS] Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries

Ants Aasma wrote: I had to make oracle_fdw work with PostgreSQL compiled using --with-ldap. The issue there is that Oracle's client library has the delightful property of linking against a ldap library they bundle that has symbol conflicts with OpenLDAP. At PostgreSQL startup libldap is

Re: [HACKERS] POLA violation with \c service=

David Fetter wrote: I've noticed that psql's \c function handles service= requests in a way that I can only characterize as broken. This came up in the context of connecting to a cloud hosting service named after warriors or a river or something, whose default hostnames are long,

Re: [HACKERS] MD5 authentication needs help

Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Bruce Momjian br...@momjian.us writes: Let me update my list of possible improvements: 1) MD5 makes users feel uneasy (though our usage is mostly safe) 2) The per-session salt sent to the client is only 32-bits, meaning that it

Re: [HACKERS] Rounding to even for numeric data type

Michael Paquier wrote: Well, I am not sure about that... But reading this thread changing the default rounding sounds unwelcome. So it may be better to just put in words the rounding method used now in the docs, with perhaps a mention that this is not completely in-line with the SQL spec if

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Etsuro Fujita wrote: While updating the patch, I noticed that in the previous patch, there is a bug in pushing down parameterized UPDATE/DELETE queries; generic plans for such queries fail with a can't-happen error. I fixed the bug and tried to add the regression tests that execute the

Re: [HACKERS] SSL renegotiation

Florian Weimer wrote: On 02/22/2015 02:05 PM, Andres Freund wrote: On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote: I honestly wonder why postgres uses renegotiation at all. The motivation that cryptoanalysis is easier as more data is sent seems quite far-fetched. I don't think so.

Re: [HACKERS] [NOVICE] psql readline Tab insert tab

Peter Eisentraut wrote: On 6/1/15 7:00 AM, Albe Laurenz wrote: Hans Ginzel wrote: how to make psql (readline) to insert tab when Tab is pressed? E.g. for pasting. I know, there is -n option. But then the history is not accessible. It could be done by adding the following lines to your

Re: [HACKERS] [NOVICE] psql readline Tab insert tab

Hans Ginzel wrote: how to make psql (readline) to insert tab when Tab is pressed? E.g. for pasting. I know, there is -n option. But then the history is not accessible. It could be done by adding the following lines to your ~/.inputrc file: $if Psql TAB: tab-insert $endif Great! Thank

Re: [HACKERS] 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors

Peter Geoghegan wrote: In any case, third party foreign data wrappers that target other database system will totally ignore ON CONFLICT DO NOTHING when built against the master branch (unless they consider these questions). They should perhaps make a point of rejecting DO NOTHING outright

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Hans-Jürgen Schönig wrote: in addition to that you have the “problem” of transactions. if you failover in the middle of a transaction, strange things might happen from the application point of view. the good thing, however, is that stupid middleware is sometimes not able to handle

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Victor Wagner wrote: Rationale = Since introduction of the WAL-based replication into the PostgreSQL, it is possible to create high-availability and load-balancing clusters. However, there is no support for failover in the client libraries. So, only way to provide transparent for

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Victor Wagner wrote: I wonder how useful this is at the present time. If the primary goes down and the client gets connected to the standby, it would have read-only access there. Most applications wouldn't cope well with that. It is supposed that somebody (either system administrator or

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Victor Wagner wrote: Idea is that we don't need any extra administration actions such as IP migration to do it. Clients have list of alternate servers and discover which one to work with by trial and error. Yes, but that will only work reliably if the (read-only) standby does not

Re: [HACKERS] Autonomous Transaction is back

Noah Misch wrote: If the autonomous transaction can interact with uncommitted work in a way that other backends could not, crazy things happen when the autonomous transaction commits and the suspended transaction aborts: CREATE TABLE t (c) AS SELECT 1; BEGIN; UPDATE t SET c =

Re: [HACKERS] Git cartoon

Fabrízio de Royes Mello wrote: > Em domingo, 8 de novembro de 2015, Bruce Momjian escreveu: >> This git cartoon was too funny not to share: >> >> http://xkcd.com/1597/ >> >> Maybe we need it on our git wiki page. ;-) > > I think we need our own cartoon with a funny

Re: [HACKERS] [PATCH] RFC: Add length parameterised dmetaphone functions

Christian Marie wrote: > A developer I work with was trying to use dmetaphone to group people names > into > equivalence classes. He found that many long names would be grouped together > when they shouldn't be, this turned out to be because dmetaphone has an > undocumented upper bound on its

[HACKERS] Documentation fix for psql

The psql documentation calls the \pset options unicode_*_style when in reality they are called unicode_*_linestyle. This should be backpatched to 9.5. Yours, Laurenz Albe 0001-Fix-documentation-for-pset-unicode_-_linestyle.patch Description:

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

Shay Rojansky wrote: > Just to give some added reasoning... > > As Andres suggested, Npgsql sends ssl_renegotiation_limit=0 because we've > seen renegotiation bugs with > the standard .NET SSL implementation (which Npgsql uses). Seems like everyone > has a difficult time > with renegotiation.

[HACKERS] Documentation for min_wal_size and max_wal_size

Wouldn't it be better to have these two parameters documented next to each other, as in the attached patch? Yours, Laurenz Albe 0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch Description: 0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch -- Sent via

Re: [HACKERS] Horizontal scalability/sharding

Etsuro Fujita wrote: > On 2015/09/02 16:40, Amit Langote wrote: >> On 2015-09-02 PM 04:07, Albe Laurenz wrote: >>> Amit Langote wrote: >>>> On 2015-09-02 PM 03:25, Amit Kapila wrote: >>>>> Will it handle deadlocks across different table partitions. C

Re: [HACKERS] Horizontal scalability/sharding

Amit Langote wrote: > On 2015-09-02 PM 03:25, Amit Kapila wrote: >> Will it handle deadlocks across different table partitions. Consider >> a case as below: >> >> T1 >> 1. Updates row R1 of T1 on shard S1 >> 2. Updates row R2 of T2 on shard S2 >> >> T2 >> 1. Updates row R2 of T2 on shard S2 >> 2.

<    1   2   3   4   5   >