>
>
> You can pass table name as text or table object id as regclass type.
>
> inside procedure you should to use dynamic sql - execute statement.
> Generally you cannot to use a variable as table or column name ever.
>
> Dynamic SQL is other mechanism - attention on SQL injection.
>
On this
On Mon, 20 May 2019 at 13:20, Andres Freund wrote:
> How
> about we have something roughly like:
>
> int numTransFnArgs = -1;
> int numCombineFnArgs = -1;
> Oid transFnInputTypes[FUNC_MAX_ARGS];
> Oid
Thomas Munro writes:
> Here's a one-off regression test failure of a sort that commit
> 624e440a intended to fix.
Note that in the discussion that led up to 624e440a, we never did
think that we'd completely explained the original irreproducible
failure.
I think I've seen a couple of other cases
On 2019/05/20 13:42, Rushabh Lathia wrote:
> On Fri, May 17, 2019 at 10:30 AM Amit Langote
>> Why not change it like this instead:
>>
>> @@ -681,7 +681,8 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid
>> ownerId,
>> Assert(list_length(inheritOids) == 1);
>> tablespaceId =
On Fri, May 17, 2019 at 10:30 AM Amit Langote
wrote:
> Agree that this behavior change seems unintentional.
>
> On 2019/05/17 12:40, Rushabh Lathia wrote:
> > Looking at the commit changes, it seems like at condition when no other
> > tablespace is specified, we default the tablespace to the
On Mon, May 20, 2019 at 10:55 AM Andres Freund wrote:
> I seem to recall that we expect tests to either work with
> default_transaction_isolation=serializable, or to set it to a different
> level where needed.
Here are a couple of bits where that is no longer necessary after bb16aba5.
--
On 2019/05/17 12:40, Rushabh Lathia wrote:
> Hi,
>
> Consider the below test:
>
> create tablespace mytbs location '/home/rushabh/mywork/workspace/pg/';
> create table test ( a int , b int ) partition by list (a);
>
> set default_tablespace to mytbs;
> create table test_p1 partition of test for
Hi,
Here's a one-off regression test failure of a sort that commit
624e440a intended to fix. a_star unexpectedly sorted higher. I
checked the space weather forecast for this morning but no sign of
solar flares. More seriously, it did the same in all 3 Parallel
Append queries. Recent commits
Hi,
On 2019-05-20 14:23:34 +1200, David Rowley wrote:
> It's not for this patch, or probably for PG12, but it would be good if
> we could avoid the formation of the Tuple until right before the new
> tuple is inserted.
>
> I see heap_form_tuple() is called 3 times for a single INSERT with:
>
>
On Thu, 16 May 2019 at 05:44, Peter Eisentraut
wrote:
> Updated patch attached.
This patch looks okay to me.
It's not for this patch, or probably for PG12, but it would be good if
we could avoid the formation of the Tuple until right before the new
tuple is inserted.
I see heap_form_tuple() is
On Fri, May 17, 2019 at 06:37:22PM -0700, Peter Geoghegan wrote:
> On Fri, May 17, 2019 at 6:36 PM Tom Lane wrote:
>> Will do so tomorrow. Should we back-patch this?
>
> I wouldn't, because I see no reason to. Somebody else might.
FWIW, I see no reason either for a back-patch.
--
Michael
Hi,
On 2019-05-20 13:25:52 +1200, Thomas Munro wrote:
> In PostgreSQL, it's always inner = right, outer = left. You can see
> that reflected in plannodes.h and elsewhere:
>
> /*
> * these are defined to avoid confusion problems with "left"
> * and "right" and
On Mon, May 20, 2019 at 10:17:31AM +0900, Fujii Masao wrote:
> I'm ok to drop this from open items for v12 because this is not a bug.
> Let's work on this next CommitFest.
Okay, I have moved out the item from the list of opened ones.
--
Michael
signature.asc
Description: PGP signature
On Mon, May 20, 2019 at 12:22 PM Tomas Vondra
wrote:
> On Mon, May 20, 2019 at 11:07:03AM +1200, Thomas Munro wrote:
> >First let me restate the PostgreSQL terminology for this stuff so I
> >don't get confused while talking about it:
> >
> >* The inner side of the join = the right side = the side
On Sun, Dec 30, 2018 at 11:28:56AM -0500, Noah Misch wrote:
> On Sun, Dec 30, 2018 at 10:41:46AM -0500, Andrew Dunstan wrote:
> > On 12/26/18 5:44 PM, Noah Misch wrote:
> > > On Wed, Dec 26, 2018 at 05:02:37PM -0500, Tom Lane wrote:
> > >> Andrew Dunstan writes:
> > >>> On 12/23/18 10:44 PM, Noah
Hi,
Thanks to all for reporting, helping to identify and finally patch the
problem!
On 2019-05-20 10:36:43 +1200, David Rowley wrote:
> On Mon, 20 May 2019 at 06:36, Andres Freund wrote:
> > > diff --git a/src/backend/executor/nodeAgg.c
> > > b/src/backend/executor/nodeAgg.c
> > > index
On Sat, May 18, 2019 at 7:19 PM Michael Paquier wrote:
>
> On Fri, May 17, 2019 at 01:11:53PM -0700, Andres Freund wrote:
> > My impression is that these are better treated as feature work, to be
> > tackled in v13. I see no urgency to push this for v12. There's still
> > some disagreements on
On Mon, May 20, 2019 at 11:07:03AM +1200, Thomas Munro wrote:
On Sat, May 18, 2019 at 12:15 PM Melanie Plageman
wrote:
On Thu, May 16, 2019 at 3:22 PM Thomas Munro wrote:
Admittedly I don't have a patch, just a bunch of handwaving. One
reason I haven't attempted to write it is because
Hi,
On 2019-05-18 18:12:31 +0300, Sergei Kornilov wrote:
> Seems table_beginscan_analyze (src/include/access/tableam.h) should not pass
> second argument as NULL.
As hopefully explained downthread, and in the commit message, that's not
really the concern. We shouldn't use the snapshot in the
On Mon, May 20, 2019 at 10:23 AM Andres Freund wrote:
> On 2019-05-19 13:57:42 +1200, Thomas Munro wrote:
> > Yeah, we could probably predicate-lock pages in
> > heapam_scan_sample_next_block() and tuples in
> > heapam_scan_sample_next_tuple(), instead of doing this. Seems like a
> > reasonable
On Sat, May 18, 2019 at 12:15 PM Melanie Plageman
wrote:
> On Thu, May 16, 2019 at 3:22 PM Thomas Munro wrote:
>> Admittedly I don't have a patch, just a bunch of handwaving. One
>> reason I haven't attempted to write it is because although I know how
>> to do the non-parallel version using a
Hi,
I seem to recall that we expect tests to either work with
default_transaction_isolation=serializable, or to set it to a different
level where needed.
Currently that's not the case. When running check-world with PGOPTIONS
set to -c default_transaction_isolation=serializable I get easy to fix
On Sun, May 19, 2019 at 02:14:54PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
No, wait, scratch that. We could fold the three existing types
pg_ndistinct, pg_dependencies, pg_mcv_list into one new type, say
"pg_stats_ext_data", where
On Mon, 20 May 2019 at 06:36, Andres Freund wrote:
> > Isn't it more due to the lack of any aggregates with > 1 arg having a
> > combine function?
>
> I'm not sure I follow? regr_count() already was in 9.6? Including a
> combine function?
Oops, that line I meant to delete before sending.
> >
Hi,
On 2019-05-19 13:57:42 +1200, Thomas Munro wrote:
> On Sun, May 19, 2019 at 8:31 AM Andres Freund wrote:
> > While looking at fixing [1] on master, I noticed the following
> > codeblock:
> >
> > static HeapScanDesc
> > heap_beginscan_internal(Relation relation, Snapshot snapshot,
> >
Hi,
Thanks for the report Joe!
I've pushed a fix for this.
I ended up going down the path of making scan_begin's arguments a
bitmask. Given that several people expressed desire for that, and that
recognizing analyze scans would have required a new argument, that
seemed the most reasonable
Hi,
On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> Ok, I have this added to everyone now.
>
> I think I also have caught up on this thread, but let me know if I
> missed anything.
I notice
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=demoiselle=2019-05-19%2014%3A22%3A23
failed
On May 19, 2019 5:59:04 PM GMT+02:00, Stephen Frost wrote:
>Greetings,
>
>* Julien Riou (jul...@riou.xyz) wrote:
>> Nowadays, PostgreSQL is often used behind proxies. Some are
>PostgreSQL
>> protocol aware (Pgpool, PgBouncer), some are pure TCP (HAProxy). From
>> the database instance point of
I wrote:
> Piotr Stefaniak writes:
>> Sorry, but GNU indent already uses -kr for something else and I would
>> like FreeBSD indent have something like that under the same name.
>> Besides, indent has too many options and this one doesn't look like
>> particularly desired by anyone. It's
Hi,
On 2019-05-19 20:18:38 +1200, David Rowley wrote:
> On Fri, 17 May 2019 at 15:04, Andres Freund wrote:
> >
> > On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> > > In a second look, I seems to me that the right thing to do here
> > > is setting numInputs instaed of numArguments to
Akim Demaille writes:
> In the following two proposed patches, I remove directives that are
> completely useless.
I'm far from convinced that the proposed changes in gram.y are a good
idea. Both [] and . (field selection) *are* left-associative in a
meaningful sense, so even if this change
Tomas Vondra writes:
> On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
>> No, wait, scratch that. We could fold the three existing types
>> pg_ndistinct, pg_dependencies, pg_mcv_list into one new type, say
>> "pg_stats_ext_data", where the actual storage would need to have an
>> ID
Piotr Stefaniak writes:
> On 19/05/2019 19.27, Tom Lane wrote:
>> Piotr Stefaniak writes:
>>> I think it's safe to assume that upstream can drop support for K
>>> parameters altogether.
>> Cool. I already created the switch, but maybe we could have it
>> default to -nkr?
> Sorry, but GNU
On 19/05/2019 19.27, Tom Lane wrote:
> Piotr Stefaniak writes:
>> On 17/05/2019 16.48, Tom Lane wrote:
>>> It doesn't really seem practical to me to make the lookahead function
>>> smart enough to tell the difference between attributes and K
>>> parameter declarations. What I'm thinking of doing
On Sun, 19 May 2019 at 15:28, Tom Lane wrote:
>
> > I wonder ... another way we could potentially do this is
>
> > create table pg_statistic_ext_data(
> > stxoid oid, -- OID of owning pg_statistic_ext entry
> > stxkind char, -- what kind of data
> > stxdata bytea -- the data, in some
On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
I wrote:
I wonder ... another way we could potentially do this is
create table pg_statistic_ext_data(
stxoid oid, -- OID of owning pg_statistic_ext entry
stxkind char, -- what kind of data
stxdata bytea -- the data, in
Hi all,
Many of the grammars could be clarified. For instance there's a number of
useless associativity and/or precedence declarations. Maybe the point is to
leave some form of a documentation, but actually, since it's not used at all by
the tool, that documentation is not checked.
In the
Piotr Stefaniak writes:
> On 17/05/2019 16.48, Tom Lane wrote:
>> It doesn't really seem practical to me to make the lookahead function
>> smart enough to tell the difference between attributes and K
>> parameter declarations. What I'm thinking of doing to have an
>> upstreamable patch is to
On 17/05/2019 16.48, Tom Lane wrote:
> I wrote:
A small problem with the "rejiggering" is that it now makes the wrong
choice for K function definitions, causing them to be weirdly
indented. For our purposes, that's a non-problem so I'm not excited
about trying to make it smart
Hi
ne 19. 5. 2019 v 18:00 odesÃlatel RAJIN RAJ K napsal:
> Hi,
>
> I'm trying to convert SAP Hana procedures in PG and i'm not able to handle
> below scenario in Postgres 11
>
> Scenario: I want to pass a table (Multiple rows) to function and use it
> inside as a temp table.
>
> Sample Code:
>
Hi,
I'm trying to convert SAP Hana procedures in PG and i'm not able to handle
below scenario in Postgres 11
Scenario: I want to pass a table (Multiple rows) to function and use it
inside as a temp table.
Sample Code:
create a table tbl_id (id int, name character varying (10));
insert few rows
Greetings,
* Julien Riou (jul...@riou.xyz) wrote:
> Nowadays, PostgreSQL is often used behind proxies. Some are PostgreSQL
> protocol aware (Pgpool, PgBouncer), some are pure TCP (HAProxy). From
> the database instance point of view, all clients come from the proxy.
>
> There are two major
Hello,
Nowadays, PostgreSQL is often used behind proxies. Some are PostgreSQL
protocol aware (Pgpool, PgBouncer), some are pure TCP (HAProxy). From
the database instance point of view, all clients come from the proxy.
There are two major problems with this topology:
* It neutralizes the host
I wrote:
> I wonder ... another way we could potentially do this is
> create table pg_statistic_ext_data(
> stxoid oid, -- OID of owning pg_statistic_ext entry
> stxkind char, -- what kind of data
> stxdata bytea -- the data, in some format or other
> );
> The advantage of this way
Dean Rasheed writes:
> I think we shouldn't risk trying to get this into beta1, but let's try
> to get it done as soon as possible after that.
Agreed.
> \d pg_statistic_ext
> Table "pg_catalog.pg_statistic_ext"
> Column|Type| Collation | Nullable | Default
>
Just throwing this out there Perhaps we should just disable toasting
for non-heap tables entirely for now?
That way at least people can use it and storage plugins just have to be
able to deal with large datums in their own (or throw errors).
On Fri., May 17, 2019, 5:56 p.m. Ashwin Agrawal,
On Sun, 19 May 2019 at 00:48, Stephen Frost wrote:
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Tomas Vondra writes:
> >
> > > I think we have four options - rework it before beta1, rework it after
> > > beta1, rework it in PG13 and leave it as it is now.
> >
> > Yup, that's about what the
On Fri, 17 May 2019 at 15:04, Andres Freund wrote:
>
> On 2019-05-08 13:06:36 +0900, Kyotaro HORIGUCHI wrote:
> > In a second look, I seems to me that the right thing to do here
> > is setting numInputs instaed of numArguments to numTransInputs in
> > combining step.
>
> Yea, to me this just
48 matches
Mail list logo
