On 2 July 2015 at 19:50, Josh Berkus wrote:
> So there's two parts to this:
>
> 1. I need to ensure that data is replicated to X places.
>
> 2. I need to *know* which places data was synchronously replicated to
> when the master goes down.
>
> My entire point is that (1) alone is useless unless
On 7 July 2015 at 07:03, Michael Paquier wrote:
> On Tue, Jul 7, 2015 at 2:19 PM, Josh Berkus wrote:
> > On 07/06/2015 09:56 PM, Michael Paquier wrote:
> >> On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus wrote:
> >>> On 07/06/2015 06:40 PM, Michael Paquier wrote:
> On Tue, Jul 7, 2015 at 2:5
On Fri, Jun 26, 2015 at 11:16 AM, Michael Paquier
wrote:
>
> On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote:
> > Let's start with a complex, fully described use case then work out how
to
> > specify what we want.
>
> Well, one of the most simple cases where quorum commit and this
> feature wo
On Wed, Jul 15, 2015 at 10:12 AM, Kouhei Kaigai wrote:
> We never guarantee the interface compatibility between major version up.
> If we add/modify interface on v9.6, it is duty for developer of extensions
> to follow the new version, even not specific to custom-scan provider.
> If v9.6 adds supp
On Fri, Jul 3, 2015 at 5:30 PM, Amit Kapila wrote:
>
>
> Attached, find the rebased patch which can be used to review/test latest
> version of parallel_seqscan patch which I am going to post in the parallel
> seq. scan thread soonish.
>
I went ahead and completed this patch with respect to adding
On 15 July 2015 at 05:58, Noah Misch wrote:
> > > If it's
> > > to stay, it *must* get a line-by-line review from some committer-level
> > > person; and I think there are other more important things for us to be
> > > doing for 9.5.
> > >
> >
> > Honestly, I am very surprised by this.
>
> Tom's
On Jul 14, 2015 7:15 AM, "Fujii Masao" wrote:
>
> On Tue, Jul 14, 2015 at 9:00 AM, Michael Paquier
> wrote:
> > On Mon, Jul 13, 2015 at 10:34 PM, Fujii Masao wrote:
> >> On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote:
> >>> On Tue, Jul 7, 2015 at 2:19 PM, Michael Paquier wrote:
> >>>
> >>>
On Tue, Jul 14, 2015 at 11:14:55AM +0100, Simon Riggs wrote:
> On 13 July 2015 at 14:39, Tom Lane wrote:
> > TBH, I think the right thing to do at this point is to revert the entire
> > patch and send it back for ground-up rework. I think the high-level
> > design is wrong in many ways and I have
> That doesn't answer my question. I'm talking about a client and server
> running on the same system with SELinux MLS policy so that getpeercon
> will return the context of the client process unless it has explicitly
> sets the socket create context . So again will postgresql if the
> sepgsql modu
On Fri, Jul 10, 2015 at 11:28 PM, Tom Lane wrote:
> Andres Freund writes:
>> On July 10, 2015 4:16:59 PM GMT+02:00, Tom Lane wrote:
>>> Would that propagate down through multiple levels of CASCADE? (Although
>>> I'm not sure it would be sensible for a non-relocatable extension to
>>> depend on
That doesn't answer my question. I'm talking about a client and server
running on the same system with SELinux MLS policy so that getpeercon
will return the context of the client process unless it has explicitly
sets the socket create context . So again will postgresql if the
sepgsql module is load
> So if I label a table with an SELinux context and the type of my
> client connection does not have policy to be able to access the table
> type will an AVC be generated and the access denied?
>
Of course, it depends on the policy of the system.
If client connection come from none-SELinux system,
Hi,
On 07/14/2015 10:19 PM, Robert Haas wrote:
On Sat, Jul 11, 2015 at 2:28 AM, Jeff Davis wrote:
After talking with a few people at PGCon, small noisy differences
in CPU timings can appear for almost any tweak to the code, and
aren't necessarily cause for major concern.
I agree with that in
> Or, taking the example of a GpuScan node, it's essentially impossible
> to persuade the planner to delegate any expensive function calculations,
> aggregates, etc to such a node; much less teach it that that way is cheaper
> than doing such things the usual way. So yeah, KaiGai-san may have a
>
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Wednesday, July 15, 2015 5:47 AM
> To: Robert Haas
> Cc: Alvaro Herrera; hlinnaka; Kaigai Kouhei(海外 浩平); Michael Paquier; Jim
> Nasby; Kohei KaiGai; PgHacker; Simon Riggs
> Subject: Re: ctidscan as an example of custo
On Mon, Jul 13, 2015 at 5:16 PM, Haribabu Kommi
wrote:
> On Mon, Jul 13, 2015 at 12:06 PM, Haribabu Kommi
> wrote:
>> On Thu, Jul 9, 2015 at 5:36 PM, Haribabu Kommi
>> wrote:
>>>
>>> I will do some performance tests and send you the results.
>>
>> Here are the performance results tested on my m
On 7/9/15 12:45 AM, Pavel Stehule wrote:
2015-07-09 7:32 GMT+02:00 Zhaomo Yang mailto:zhy...@cs.ucsd.edu>>:
> I am not sure, if it is not useless work.
I don't understand why an implementation taking approach 2.a would
be useless. As I said, its performance will be no worse than c
Robert Haas writes:
> Both you and Andres have articulated the concern that CustomScan isn't
> actually useful, but I still don't really understand why not.
> I'm curious, for example, whether CustomScan would have been
> sufficient to build TABLESAMPLE, and if not, why not. Obviously the
> synt
On 7/7/15 7:07 AM, Andres Freund wrote:
On 2015-07-03 18:03:58 -0400, Tom Lane wrote:
I have just looked through this thread, and TBH I think we should reject
this patch altogether --- not RWF, but "no we don't want this". The
use-case remains hypothetical: no performance numbers showing a real
On Tue, Jul 7, 2015 at 6:33 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
>
> See Tom Lane's comment about downgrade scripts. I think just remove it is
> a right solution.
>
The new patch removes the downgrade path and the ability to install the old
version.
(If anyone wants an ea
On Tue, Jul 14, 2015 at 4:47 PM, Tom Lane wrote:
> I think this ties into my core unhappiness with the customscan stuff,
> which is that I don't believe it's *possible* to do anything of very
> great interest with it. I think anything really useful will require
> core code modifications and/or ho
Robert Haas writes:
> On Tue, Jul 14, 2015 at 3:07 PM, Alvaro Herrera
> wrote:
>> As a general principle, I think it's a good idea to have a module that's
>> mostly just a skeleton that guides people into writing something real to
>> use whatever API is being tested. It needs to be simple enough
On Tue, Jul 14, 2015 at 12:45 PM, Robert Haas wrote:
> OK, now I understand.
Thanks.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jul 11, 2015 at 2:28 AM, Jeff Davis wrote:
> After talking with a few people at PGCon, small noisy differences in CPU
> timings can appear for almost any tweak to the code, and aren't
> necessarily cause for major concern.
I agree with that in general, but the concern is a lot bigger when
On Tue, Jul 14, 2015 at 1:39 PM, Peter Geoghegan wrote:
> On Tue, Jul 14, 2015 at 10:28 AM, Robert Haas wrote:
>> And what, in your opinion, is the issue?
>
> The test does not match the comment above it. It looks like someone
> (possibly me) pasted one too many template queries, that were never
On Tue, Jul 14, 2015 at 3:07 PM, Alvaro Herrera
wrote:
>> We don't have anything that currently tests the Custom Scan interface
>> in the tree. The question is how important that is, and whether it's
>> worth having what's basically a toy implementation just to demonstrate
>> that the feature can
On 14 July 2015 at 13:59, Robert Haas wrote:
> On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway wrote:
>> On 06/08/2015 02:08 AM, Dean Rasheed wrote:
>>> Actually I think it is fixable just by allowing the CURRENT OF
>>> expression to be pushed down into the subquery through the
>>> security barrier vi
Robert Haas wrote:
> We don't have anything that currently tests the Custom Scan interface
> in the tree. The question is how important that is, and whether it's
> worth having what's basically a toy implementation just to demonstrate
> that the feature can work. If so, I think ctidscan is as go
On Tue, Jul 14, 2015 at 11:40 AM, Gianni wrote:
> Could there be a version of UPSERT where an update is tried, and if 0 records
> are modified, an insert is done?
>
> Just wondering, I haven't got am use-case for that. I don't mid gaps in
> sequences.
Perhaps, if you don't mind having a severely
Yes Michael, I agree.
This is the CloseArchive function at pg_backup_custom.c
WriteHead(AH);
tpos = ftello(AH->FH);
WriteToc(AH);
ctx->dataStart = _getFilePos(AH, ctx);
WriteDataChunks(AH);
This is the WriteHead function at pg_backup_archiver.c:
(*AH->WriteBufPtr) (AH, "PGDMP", 5); /* Magic cod
On Mon, Jul 6, 2015 at 12:52 PM, Alvaro Herrera
wrote:
> I suggest CC'ing Peter as a first measure. I already suggested this (or
> something similar) to him months ago.
This would be a worthwhile effort. tuplesort.c only has 46% coverage.
There is no coverage for functions that I know are used a
On Tuesday 14 July 2015 11:33:34 Peter Geoghegan wrote:
> On Sun, Jul 12, 2015 at 4:09 AM, Yourfriend wrote:
> > Suggestion: When a conflict was found for UPSERT, don't access the
> > sequence, so users can have a reasonable list of ID.
>
> This is not technically feasible. What if the arbiter i
On Sun, Jul 12, 2015 at 4:09 AM, Yourfriend wrote:
> Suggestion: When a conflict was found for UPSERT, don't access the
> sequence, so users can have a reasonable list of ID.
This is not technically feasible. What if the arbiter index is a serial PK?
The same thing can happen when a transaction
Peter Eisentraut wrote:
> On 7/14/15 3:44 AM, Alvaro Herrera wrote:
> > I have been using a slightly tweaked version of this and I have found
> > that the %w(80,4,4)%B thingy results in mangled formatting;
>
> I have since refined this to
>
> ... %n%n%w(0,4,4)%s%n%+b
>
> You might find that tha
On 7/14/15 3:44 AM, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> On 6/25/15 8:08 PM, Robert Haas wrote:
>>> Because I don't want to have to do git log --format=fuller to see when
>>> the thing was committed, basically.
>>
>> Then I suggest to you the following configuration settings:
>>
>> [f
On Wed, Jul 15, 2015 at 12:55 AM, Simon Riggs wrote:
> On 10 July 2015 at 15:11, Sawada Masahiko wrote:
>>
>>
>> Oops, I had forgotten to add new file heapfuncs.c.
>> Latest patch is attached.
>
>
> I think we've established the approach is desirable and defined the way
> forwards for this, so th
So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?
Ted
On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai wrote:
> 2015-07-15 2:39 GMT+09:00 Ted Toth :
>> That's e
2015-07-15 2:39 GMT+09:00 Ted Toth :
> That's exactly what I'm talking about like I said KaiGais branch was
> never merged into the mainline so I do not believe that it is used at
> all.
>
It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based sec
On Tue, May 26, 2015 at 4:58 AM, Uriy Zhuravlev
wrote:
> Hello.
>
> Attached patch based on:
>
> http://www.postgresql.org/message-id/capphfdssy+qepdcovxx-b4lp3ybr+qs04m6-arggknfk3fr...@mail.gmail.com
>
> and adds selectivity estimation functions to @@ (port from tsquery). Now we
> support &&, @>
Fujii Masao wrote:
> Sometimes I type TAB after \ to display all the psql meta commands.
> Even single-character completion like \s may be useful for that case.
> Yeah, I agree that's narrow use case, though.
I agree that that's useful, so thanks for having pushed it.
--
Álvaro Herrera
Michael Paquier wrote:
> On Mon, Jul 13, 2015 at 9:03 PM, Sawada Masahiko
> wrote:
> > We use script file which are generated by pg_upgrade.
>
> I haven't followed this thread closely, but I am sure you recall that
> vacuumdb has a parallel mode.
I think having to vacuum the whole database dur
Peter Eisentraut wrote:
> On 6/25/15 8:08 PM, Robert Haas wrote:
> > Because I don't want to have to do git log --format=fuller to see when
> > the thing was committed, basically.
>
> Then I suggest to you the following configuration settings:
>
> [format]
> pretty=cmedium
> [pretty]
>
On Tue, Jul 14, 2015 at 10:28 AM, Robert Haas wrote:
> And what, in your opinion, is the issue?
The test does not match the comment above it. It looks like someone
(possibly me) pasted one too many template queries, that were never
appropriately modified to fit the area under consideration.
--
That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.
Ted
On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas wrote:
> On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth wrote:
>> I'm sort of new to this so maybe I'm mis
On 7/13/15 4:02 PM, David Christensen wrote:
On Jul 13, 2015, at 3:50 PM, Jim Nasby wrote:
On 7/13/15 3:26 PM, David Christensen wrote:
* Incremental Checksums
PostgreSQL users should have a way up upgrading their cluster to use data
checksums without having to do a costly pg_dump/pg_resto
On Tue, Jul 14, 2015 at 1:26 PM, Peter Geoghegan wrote:
> On Tue, Jul 14, 2015 at 9:27 AM, Robert Haas wrote:
>> Removing that test doesn't seem important to me. Why does it seem
>> important to you?
>
> It's a minor issue, but it's easily fixed.
And what, in your opinion, is the issue?
--
Ro
On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth wrote:
> I'm sort of new to this so maybe I'm missing something but since the
> sepgsql SELinux userspace object manager was never integrated into
> postgresql (AFAIK KaiGais branch was never merged into the mainline)
> who uses these labels? What use are
On Tue, Jul 14, 2015 at 9:27 AM, Robert Haas wrote:
> Removing that test doesn't seem important to me. Why does it seem
> important to you?
It's a minor issue, but it's easily fixed.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?
Ted
On Tue, Jul 14, 2015 at 12:09 PM, Adam Brightw
All,
>> I won't have time to do anything about this anytime soon, but I think we
>> should fix that at some point. Shall I put this on the todo? Or do we
>> want to create an 'open items' page that's not major version specific?
>
> I think adding it to the TODO would be great.
I'd be willing to
Thom Brown writes:
> On 14 July 2015 at 17:17, Robert Haas wrote:
>> Since it's trivial to define this function if you need it, I'm not
>> sure there's a reason to include it in core.
> It's not always possible to create functions on a system when access
> is restricted. It may even be the case
On 07/14/2015 07:28 PM, Jeff Janes wrote:
I'm getting some compiler warnings now:
operatorcmds.c: In function 'AlterOperator':
operatorcmds.c:504: warning: 'address.objectSubId' may be used
uninitialized in this function
operatorcmds.c:365: note: 'address.objectSubId' was declared here
operatorc
On Mon, Jul 13, 2015 at 11:56 AM, Andrew Dunstan
wrote:
>
> On 07/13/2015 01:12 PM, Smitha Pamujula wrote:
>
>> Yes. I have checked that the extension didn't exist in any of the
>> databases. I used \dx to see if there was json_build was listed and i didnt
>> see any. Is that sufficient to check
On 14 July 2015 at 17:17, Robert Haas wrote:
>
> On Tue, Jul 14, 2015 at 10:52 AM, Thom Brown wrote:
> > When using currval() to find the current value of all sequences, it chokes
> > on those that aren't initialised. This is expected and documented as
> > behaving in this manner. However, I th
On Tue, Jul 14, 2015 at 8:22 AM, Heikki Linnakangas wrote:
> On 07/13/2015 03:43 PM, Uriy Zhuravlev wrote:
>
>> Hello hackers.
>>
>> Attached is a new version of patch:
>> * port syntax from NULL to truth NONE
>> * fix documentation (thanks Heikki)
>> * rebase to master
>>
>
> Thanks, committed
On Fri, Jul 10, 2015 at 2:56 PM, Peter Geoghegan wrote:
> On Tue, Jun 2, 2015 at 3:11 PM, Peter Geoghegan wrote:
>> Here is another patch, this time removing a useless ON CONFLICT DO UPDATE
>> test.
>
> Can someone commit this, please?
Removing that test doesn't seem important to me. Why does
On Fri, Jul 10, 2015 at 8:55 AM, Heikki Linnakangas wrote:
>> If somebody still needs it, I'll rebase and adjust the patch towards
>> the latest custom-scan interface. However, I cannot be motivated for
>> the feature nobody wants.
>
> Robert, can you weigh in on this? Do we currently have anythin
On Tue, Jul 14, 2015 at 10:52 AM, Thom Brown wrote:
> When using currval() to find the current value of all sequences, it chokes
> on those that aren't initialised. This is expected and documented as
> behaving in this manner. However, I think it would be useful to also
> support retrieving the
On Tue, Jul 14, 2015 at 11:05 AM, Thom Brown wrote:
> On 14 July 2015 at 16:02, David G. Johnston
> wrote:
>
>> On Tue, Jul 14, 2015 at 10:52 AM, Thom Brown wrote:
>>
>>> The use-case I have in mind is for finding out how close to the 32-bit
>>> integer limit sequences have reached. At the mom
On 10 July 2015 at 15:11, Sawada Masahiko wrote:
>
> Oops, I had forgotten to add new file heapfuncs.c.
> Latest patch is attached.
>
I think we've established the approach is desirable and defined the way
forwards for this, so this is looking good.
Some of my requests haven't been actioned yet
On Tuesday 14 July 2015 18:22:26 you wrote:
> I think you had copy-pasted from one of the generic
> ALTER variants, like AlterOwnerStmt, which was overly generic for ALTER
> OPERATOR.
You right.
> Thanks, committed after some editing.
Thanks you. And it BIG editing. ;)
After that, can you vi
On 07/13/2015 03:43 PM, Uriy Zhuravlev wrote:
Hello hackers.
Attached is a new version of patch:
* port syntax from NULL to truth NONE
* fix documentation (thanks Heikki)
* rebase to master
Thanks, committed after some editing. I put all the logic into
AlterOperator function, in operatorcmd
On 14 July 2015 at 16:02, David G. Johnston
wrote:
> On Tue, Jul 14, 2015 at 10:52 AM, Thom Brown wrote:
>
>> The use-case I have in mind is for finding out how close to the 32-bit
>> integer limit sequences have reached. At the moment, this isn't possible
>> without creating a custom function
On Tue, Jul 14, 2015 at 10:52 AM, Thom Brown wrote:
> The use-case I have in mind is for finding out how close to the 32-bit
> integer limit sequences have reached. At the moment, this isn't possible
> without creating a custom function to go fetch the last_value from the
> specified sequence.
>
On 14 July 2015 at 15:32, Tom Lane wrote:
> Simon Riggs writes:
> > On 13 July 2015 at 14:39, Tom Lane wrote:
> >> TBH, I think the right thing to do at this point is to revert the entire
> >> patch and send it back for ground-up rework. I think the high-level
> >> design is wrong in many ways
Hi all,
When using currval() to find the current value of all sequences, it chokes
on those that aren't initialised. This is expected and documented as
behaving in this manner. However, I think it would be useful to also
support retrieving the current value of a sequence, regardless of whether
i
Simon Riggs writes:
> On 13 July 2015 at 14:39, Tom Lane wrote:
>> TBH, I think the right thing to do at this point is to revert the entire
>> patch and send it back for ground-up rework. I think the high-level
>> design is wrong in many ways and I have about zero confidence in most
>> of the co
Robert Haas writes:
> I really think we should do the simple thing first. If we make this
> complicated and add lots of bells and whistles, it is going to be much
> harder to get anything committed, because there will be more things
> for somebody to object to. If we start with something simple,
Hi,
On 07/13/2015 10:51 AM, Kyotaro HORIGUCHI wrote:
Ok, I understood the diferrence between what I thought and what you
say. The code is actually concious of OR clause but is looks somewhat
confused.
I'm not sure which part is confused by the OR clauses, but it's
certainly possible. Initial
The above implementation of "first" aggregate returns the first non-NULL item
value.
To get *first row item value* for a column use the below implementation.
-- create a function that push at most two element on given array
-- push the first row value at second index of the array
CREATE OR REP
On Thu, Jul 9, 2015 at 9:43 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Pushed, thanks.
>
> Shouldn't we consider back-patching these improvements into 9.5 and 9.4?
> ISTM the main point is to help debug buildfarm failures, and we won't be
> getting much benefit if only one-third of such
On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway wrote:
> On 06/08/2015 02:08 AM, Dean Rasheed wrote:
>> Actually I think it is fixable just by allowing the CURRENT OF
>> expression to be pushed down into the subquery through the
>> security barrier view. The planner is then guaranteed to generate a
>>
On Fri, Jul 10, 2015 at 7:57 AM, Andres Freund wrote:
> pg_dump dumps security labels on databases. Which makes sense. The
> problem is that they're dumped including the database name.
>
> Which means that if you dump a database and restore it into a
> differently named one you'll either get a fai
On Fri, Jul 10, 2015 at 12:33 PM, Alexander Korotkov
wrote:
> I can propose following:
>
> 1) Expose more information about current lock to user. For instance, having
> duration of current wait event, user can determine if backend is getting
> stuck on particular event without sampling.
Although
On Tue, Jul 14, 2015 at 3:46 AM, Stephen Frost wrote:
> Fujii,
>
> * Fujii Masao (masao.fu...@gmail.com) wrote:
>> he documents of the functions which the corresponding default roles
>> are added by this patch need to be updated. For example, the description
>> of pg_xlog_replay_pause() says "Paus
On Tue, Jul 14, 2015 at 4:23 PM, Andrew Gierth
wrote:
> > "Jeevan" == Jeevan Chalke writes:
>
> Jeevan> Basically, when we have only one element in GROUING SETS, we
> Jeevan> are assuming it as a simple GROUP BY with one column. Due to
> Jeevan> which we are ending up with this error.
>
>
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Basically, when we have only one element in GROUING SETS, we
Jeevan> are assuming it as a simple GROUP BY with one column. Due to
Jeevan> which we are ending up with this error.
Jeevan> If we have ROLLUP/CUBE or GROUPING SETS with multiple elem
On 13 July 2015 at 14:39, Tom Lane wrote:
> Michael Paquier writes:
> > Regarding the fact that those two contrib modules can be part of a
> > -contrib package and could be installed, nuking those two extensions
> > from the tree and preventing the creating of custom tablesample
> > methods look
Hi,
I have observed some fishy behavior related to GROUPING in HAVING clause
and when we have only one element in GROUPING SETS.
Basically, when we have only one element in GROUING SETS, we are assuming
it as a simple GROUP BY with one column. Due to which we are ending up with
this error.
If we
On 07/14/2015 10:29 AM, Michael Paquier wrote:
On Tue, Jul 14, 2015 at 1:42 AM, Heikki Linnakangas wrote:
I plan to commit the attached patches later today or tomorrow. But how do
you feel about back-patching this? It should be possible to backpatch,
although at a quick test it seems that there
On Tue, Jul 14, 2015 at 1:42 AM, Heikki Linnakangas wrote:
> There was one bug in this patch: the COMMENT statement that was constructed
> didn't schema-qualify the relation, so if the ALTERed table was not in
> search_path, the operation would fail with a "relation not found" error (or
> add the c
81 matches
Mail list logo
