On Tue, Aug 16, 2022 at 9:04 PM Bruce Momjian wrote:
>
> On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote:
> > I have updated the patch to display "Objects depending on extension"
> > as describe extension footer. The changes for the same are available
On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote:
> I have updated the patch to display "Objects depending on extension"
> as describe extension footer. The changes for the same are available
> in the v2 version patch attached. Thoughts?
I wonder if we would b
On Sun, Aug 14, 2022 at 10:24 PM vignesh C wrote:
>
> On Sun, Aug 14, 2022 at 11:07 AM Tom Lane wrote:
> >
> > vignesh C writes:
> > > Currently we do not include the dependent extension information for
> > > index and materialized view in the describe comm
On Sun, Aug 14, 2022 at 11:07 AM Tom Lane wrote:
>
> vignesh C writes:
> > Currently we do not include the dependent extension information for
> > index and materialized view in the describe command. I felt it would
> > be useful to include this information as part
vignesh C writes:
> Currently we do not include the dependent extension information for
> index and materialized view in the describe command. I felt it would
> be useful to include this information as part of the describe command
> like:
> \d+ idx_depends
>
Hi,
Currently we do not include the dependent extension information for
index and materialized view in the describe command. I felt it would
be useful to include this information as part of the describe command
like:
\d+ idx_depends
Index "public.idx_depends"
Colu
On Wed, Aug 25, 2021 at 05:10:57AM +, wangsh.f...@fujitsu.com wrote:
> Delete first if statement, patch attached.
Indeed, this looks like a mismerge. I'll apply that in a bit.
Funnily, Coverity did not mention that.
--
Michael
signature.asc
Description: PGP signature
Hi,
I find in ecpg.header, the source:
> if (connection)
> if (connection && strcmp(ptr->connection, connection)
> != 0)
The first if statement is useless. And in fix-ecpg-tests.patch:
>- if (connection)
>-
Hi,
Sorry for being late. I had a vaccination.
I'm not sure about the rule that stderr should be removed
even if the pre-compiling state, but anyway I agree that
the warned case is not expected.
The wrong message is perfectly fault...
I confirmed your commit and I think it's OK. Thanks!
Best Re
On Tue, Aug 17, 2021 at 03:34:28PM +0900, Michael Paquier wrote:
> On Mon, Aug 16, 2021 at 12:06:16PM +0200, Michael Meskes wrote:
>> You patch removes the warning but by doing that also removes the
>> feature that is being tested.
>
> Oops. If kept this way, this test scenario is going to need a
On Mon, Aug 16, 2021 at 12:06:16PM +0200, Michael Meskes wrote:
> You patch removes the warning but by doing that also removes the
> feature that is being tested.
Oops. If kept this way, this test scenario is going to need a comment
to explain exactly that.
> I'm not sure what's the best way to
> > (1) There should be no output to stderr in the tests. Why isn't
> > this
> > message being caught and redirected to the normal test output file?
>
> These are generated during the compilation of the tests with the
> pre-processor, so that's outside the test runs.
This is actually a deeper is
On Wed, Aug 11, 2021 at 10:41:59PM +0200, Michael Meskes wrote:
> I'm not sure I understand. Any usage of DECLARE STATEMENT makes the
> file need the current version of ecpg anyway. On the other hand
> DEALLOCATE did not change its behavior if no DECLARE STATEMENT was
> issued, or what did I miss?
On Sat, Aug 14, 2021 at 11:08:44PM -0400, Tom Lane wrote:
> Please do something about that.
>
> (1) There should be no output to stderr in the tests. Why isn't this
> message being caught and redirected to the normal test output file?
These are generated during the compilation of the tests with
Michael Meskes writes:
> I will commit the patch(es). Thanks.
This commit appears to be responsible for new noise on stderr
during check-world:
$ make -s check-world >/dev/null
declare.pgc:123: WARNING: connection "con2" is overwritten to "con1".
declare.pgc:124: WARNING: connection "con2" is ov
> No, you're right, although I think it's implied. Maybe we need a
> statement along these lines:
>
>
> Committers are responsible for the resolution of open items that
> relate
> to commits they have made. Action needs to be taken in a timely
> fashion,
> and if there is any substantial delay in
> Sure, DECLARE does not matter as it is new. However, please note
> that
> the specific point I was trying to make with my link [2] from
> upthread
> is related to the use of cached connection names with DEALLOCATE, as
> of this line in the new test declare.pgc:
> EXEC SQL DEALLOCATE PREPARE
On Tue, Aug 10, 2021 at 09:31:37AM +0200, Michael Meskes wrote:
>> that it could be a good thing. declare.pgc seems to rely on that
>> already but the tests are incorrect as I mentioned in [2]. For
>> DESCRIBE, that provides data about a result set, I find the
>> assignm
On Tue, Aug 10, 2021 at 1:46 PM Andrew Dunstan wrote:
> No, you're right, although I think it's implied. Maybe we need a
> statement along these lines:
I agree with that, but to me it's more in the scope of what is
expected of committers in general. At a very high level. So it's not
something tha
On 8/10/21 2:16 PM, Michael Meskes wrote:
>> Agreed. How is this, which already exists?
>>
>> https://wiki.postgresql.org/wiki/Release_Management_Team
> That I know, but I don't think it covers the issues we, or I, had up-
> thread. Or do I miss something?
No, you're right, although I
> Agreed. How is this, which already exists?
>
> https://wiki.postgresql.org/wiki/Release_Management_Team
That I know, but I don't think it covers the issues we, or I, had up-
thread. Or do I miss something?
Speaking of RMT, Andrew, Michael, Peter, will you make the final
decision wheth
On Tue, Aug 10, 2021 at 08:05:29PM +0200, Michael Meskes wrote:
> > I think my point was that committers should be required to understand
> > the RMT process, and if we need to communicate that better, let's do
> > that. I don't think it should be the responsibility of RMT members
> > to
> > commu
> I think my point was that committers should be required to understand
> the RMT process, and if we need to communicate that better, let's do
> that. I don't think it should be the responsibility of RMT members
> to
> communicate the RMT process every time they communicate with someone,
> unless
On Tue, Aug 10, 2021 at 09:37:19AM +0200, Michael Meskes wrote:
> > I do think all committers need to understand the role of the RMT so
> > they
> > can respond appropriately. Do we need to communicate this better?
>
> Being the one who assumed a different procedure, yes please. :)
I think my po
Dear Meskes and any hackers,
> Yes, at least technically. I think DESCRIBE should accept the cached
> connection name, although it won't really matter.
I sought docs too and I found that Pro*C have such a same policy,
so it might be reasonable:
https://docs.oracle.com/en/database/or
> I do think all committers need to understand the role of the RMT so
> they
> can respond appropriately. Do we need to communicate this better?
Being the one who assumed a different procedure, yes please. :)
Thanks,
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (
> Okay. So you mean to change DESCRIBE and DEALLOCATE to be able to
> handle cached connection names, as of [1]? For [DE]ALLOCATE, I agree
Yes, at least technically. I think DESCRIBE should accept the cached
connection name, although it won't really matter.
> that it could b
Peter,
> I think that there was a snowballing effect here. We both made
> mistakes that compounded. I apologize for my role in this whole mess.
Completely agreed. I think we both took things for granted that the
other one didn't take into account at all. I'm sorry about that, too.
Michael
--
e) that
>> the
>> patch affects the behavior of DECLARE, PREPARE, and EXECUTE, but not
>> DESCRIBE, DEALLOCATE, DECLARE CURSOR .. FOR, or CREATE TABLE AS
>> EXECUTE. However, it also seems that it's not entirely clear what the
>> behavior ought to be in those cases,
On Mon, Aug 9, 2021 at 3:51 PM Bruce Momjian wrote:
> > I think that there was a snowballing effect here. We both made
> > mistakes that compounded. I apologize for my role in this whole mess.
>
> I do think all committers need to understand the role of the RMT so they
> can respond appropriately.
On Mon, Aug 9, 2021 at 03:42:45PM -0700, Peter Geoghegan wrote:
> > I'd like to apologize for not answering your email the way I should
> > have. Honestly it never occurred to me. Maybe that's because I'm used
> > to other procedures, or because I never had to converse with the RMT,
> > or maybe,
Michael,
On Mon, Aug 9, 2021 at 3:03 PM Michael Meskes wrote:
> This explains why it felt so difficult to make myself clear. I was
> feeling exactly the same, just the other way round.
My own special brand of miscommunication was also involved. I happen
to be sensitive to the perception that I y
On 8/9/21 6:15 PM, Bruce Momjian wrote:
> On Tue, Aug 10, 2021 at 12:03:24AM +0200, Michael Meskes wrote:
>> I'd like to apologize for not answering your email the way I should
>> have. Honestly it never occurred to me. Maybe that's because I'm used
>> to other procedures, or because I never had
> > Again agreed, please keep in mind, though, that I didn't notice I
> > was
> > being chased until Peter's first email.
>
> I was asked by the RMT to contact one of your employees, and I did,
> to
> tell you that the RMT was looking for feedback from you on an ecpg
> issue. Not sure if that was
On Tue, Aug 10, 2021 at 12:03:24AM +0200, Michael Meskes wrote:
> I'd like to apologize for not answering your email the way I should
> have. Honestly it never occurred to me. Maybe that's because I'm used
> to other procedures, or because I never had to converse with the RMT,
> or maybe, quite sim
On Mon, Aug 9, 2021 at 06:00:00PM -0400, Bruce Momjian wrote:
> > Again agreed, please keep in mind, though, that I didn't notice I was
> > being chased until Peter's first email.
>
> I was asked by the RMT to contact one of your employees, and I did, to
> tell you that the RMT was looking for fe
Peter,
> I think that this must be a cultural thing. I can see how somebody
> would see the third person style as overly formal or stilted. An
> interpretation like that does make sense to me. But I knew of no
> reason why you might find that style made the message offensive. It
> was never intend
On Mon, Aug 9, 2021 at 11:48:07PM +0200, Michael Meskes wrote:
> No, of course not. And sorry for not being precise enough, I only
> objected to the prediction part, but I agree, I take the objection
> back. I guess it's as difficult for Peter to understand why this is
> offensive as it is for me
> > > I don't want to upset anybody for any reason. I regret that my
> > > words
> > > have upset you, but I think that they were misinterpreted in a
> > > way
> > > that I couldn't possibly have predicted. The particular aspect of
> >
> > I strongly object to that. It's pretty obvious to me that
On Mon, Aug 9, 2021 at 1:38 PM Michael Meskes wrote:
> > I don't want to upset anybody for any reason. I regret that my words
> > have upset you, but I think that they were misinterpreted in a way
> > that I couldn't possibly have predicted. The particular aspect of
>
> I strongly object to that.
On Mon, Aug 9, 2021 at 10:38:07PM +0200, Michael Meskes wrote:
> > Clearly we disagree about this. I don't think that there is anything
> > to be gained from discussing this any further, though. I suggest that
> > we leave it at that.
>
> Agreed.
>
> > I don't want to upset anybody for any reaso
On Mon, Aug 9, 2021 at 1:38 PM Michael Meskes wrote:
> > I don't want to upset anybody for any reason. I regret that my words
> > have upset you, but I think that they were misinterpreted in a way
> > that I couldn't possibly have predicted. The particular aspect of
>
> I strongly object to that.
ead is whether there's really a bug here at all. It is being
> represented (and I have not checked whether this is accurate) that
> the
> patch affects the behavior of DECLARE, PREPARE, and EXECUTE, but not
> DESCRIBE, DEALLOCATE, DECLARE CURSOR .. FOR, or CREATE TABLE AS
>
> question with a question mark. Despite the fact that it is generally
> understood that "committers own their own items", and that the RMT
> exists as a final check on that.
This does not contradict my opinion, but anyway.
> Clearly we disagree about this. I don't think that there is anything
>
n that I have reading over
this thread is whether there's really a bug here at all. It is being
represented (and I have not checked whether this is accurate) that the
patch affects the behavior of DECLARE, PREPARE, and EXECUTE, but not
DESCRIBE, DEALLOCATE, DECLARE CURSOR .. FOR, or CREATE TAB
On Mon, Aug 9, 2021 at 11:45 AM Michael Meskes wrote:
> If you want me to answer, how about asking a question? Or telling me
> that you'd like some feedback? I don't see how I should know that you
> expect a reply to a simple statement of facts.
I expressed concern in fairly strong terms, and rec
> My email of July 30 was itself pretty strongly worded, but went
> unanswered for a full week. Not even a token response. If that
> doesn't
> count as "ignoring the RMT", then what does? How much time has to
> pass
> before radio silence begins to count as "ignoring the RMT", in your
> view of thi
On Mon, Aug 9, 2021 at 12:10 AM Michael Meskes wrote:
> How do you know I didn't spend 15 minutes looking at the patch and the
> whole email thread? I surely did and it was more than 15 minutes, but
> not enough to give a meaningful comment. If you can do it in 15
> minutes, great for you, I canno
RE STATEMENT has been added from PG14, but I
> found that connection-control feature cannot be used for DEALLOCATE
> and DESCRIBE statement (More details, please see patches or ask me).
> But we have a question - what statement should use the associated
> connection? Obviously DEALLOCATE
Dear Horiguchi-san,
> How Pro*C behaves in that case? If the second command ends with an
> error, I think we are free to error out the second command before
> execution. If it works... do you know what is happening at the time?
You asked that how Oracle works when the followings precompiled and
e
Dear Wang,
Good reporting!
> I'm not sure, but how about modify the ecpg.trailer:
> > statement: ecpgstart at toplevel_stmt ';' { connection = NULL; }
> > | ecpgstart toplevel_stmt ';'
> I think there are lots of 'connection = NULL;' in source, and we should find a
good location to reset the conn
w this to drag on indefinitely.
Of cause I will try to avoid it but I can understand doing your business.
Dear Meskes,
I summarize the thread.
As you might know DECLARE STATEMENT has been added from PG14, but I
found that connection-control feature cannot be used for DEALLOCATE
and DESCRIBE s
> I think that it's crystal clear what I meant in the email of July 30.
> I meant: it's not okay that you're simply ignoring the RMT. You
> hadn't
> even made a token effort at that point. For example you didn't give
> the proposed fix a cursory 15 minute review, just so we had some very
> rough id
On Sun, Aug 8, 2021 at 11:34 AM Michael Meskes wrote:
> > https://postgr.es/m/CAH2-Wzk=qxtsp0h5ekv92eh0u22hvmqlhgwyp4_fa3ytiei...@mail.gmail.com
>
> This email said nothing about sending a status update or a deadline or
> any question at all, only that you'd revert the patch if I was unable
> to r
On Sat, 2021-08-07 at 15:31 -0700, Peter Geoghegan wrote:
> On Sat, Aug 7, 2021 at 12:43 PM Michael Meskes
> wrote:
> > Again, I didn't know the RMT was expecting anything from me. Yes, I
> > knew I needed to spend some time on a technical issues, but that's
> > exactly the information I had at th
On Sat, Aug 7, 2021 at 12:43 PM Michael Meskes wrote:
> Again, I didn't know the RMT was expecting anything from me. Yes, I
> knew I needed to spend some time on a technical issues, but that's
> exactly the information I had at the time.
As Andrew mentioned, I sent you an email on the 30th -- a f
On 8/7/21 3:43 PM, Michael Meskes wrote:
>
>> No other committer (certainly nobody on the RMT) knows anything about
>> ecpg. How much longer were you expecting us to wait for a simple
>> status update?
> Where did I say I expect you to wait? How could I even do that given
> that I didn't even kno
> That's simply not true. Andrew Dunstan reached out personally and got
> no response. He then reached out through a backchannel (a direct
> coworker of yours), before finally getting a single terse response
> from you here.
You do know that I did not receive any email from Andrew. After all I
exp
On Sat, Aug 7, 2021 at 1:13 AM Michael Meskes wrote:
> I get it that the goal is to release PostgreSQL 14 and I also get it
> that nobody is interested in the reasons for my slow reaction. I even,
> at least to an extend, understand why nobody tried reaching out to me
> directly.
That's simply no
Hi Peter,
> The RMT continues to be concerned about the lack of progress on this
> open item, especially the lack of communication from Michael Meskes,
> the committer of the original patch (commit ad8305a). We are prepared
> to exercise our authority to resolve open items directly. The only
> fal
On Fri, Jul 30, 2021 at 3:01 PM Peter Geoghegan wrote:
> The RMT discussed this recently. We are concerned about this issue,
> including how it has been handled so far.
>
> If you're unable to resolve the issue (or at least commit time to
> resolving the issue) then the RMT will call for the rever
On Thu, Jul 29, 2021 at 12:22 PM Michael Meskes wrote:
> I just wanted to let you know that I'm well aware of this thread but
> need to get through my backlog before I can comment. Sorry for the
> delay.
The RMT discussed this recently. We are concerned about this issue,
including how it has been
All,
> between DECLARE and the past queries qualify as an open item. I am
> adding Michael Meskes in CC. I got to wonder how much of a
> compatibility break it would be for DEALLOCATE and DESCRIBE to handle
> EXEC SQL AT in a way more consistent than DECLARE, even if these are
&g
Hello, Kuroda-san.
At Mon, 12 Jul 2021 04:05:21 +, "kuroda.hay...@fujitsu.com"
wrote in
> > Similary, the following sequence doesn't yield an error, which is
> > expected.
> >
> > > EXEC SQL AT conn1 DECLARE stmt STATEMENT;
> > > EXEC SQL AT conn2 EXECUTE stmt INTO ..;
> >
> > In this cas
---Original Message-
From: kuroda.hay...@fujitsu.com
Sent: Monday, July 12, 2021 12:05 PM
To: 'Kyotaro Horiguchi'
Cc: pgsql-hackers@lists.postgresql.org
Subject: RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Dear Horiguchi-san,
Thank you for reviewing! I attac
Dear Horiguchi-san,
Thank you for reviewing! I attached new version.
Sorry for delaying reply.
> Since we don't allow descriptors with the same name even if they are
> for the different connections, I think we can set the current
> connection if any (which is set either by AT option or statement-
On Thu, Jul 08, 2021 at 11:42:14AM +, kuroda.hay...@fujitsu.com wrote:
> I already said above, I think that DEALLOCATE statement should
> follow the linked connection, but I cannot decide about DESCRIBE.
> I want to ask how do you think.
I am not completely sure. It would be goo
ng to need more time to finish evaluating this patch, but it
> seems that this moves to the right direction. The new warnings for
> lookup_descriptor() and drop_descriptor() with the connection name are
> useful. Should we have more cases with con2 in the new set of tests
> for DESCRI
some of the names are spelled wrongly until
runtime. If it were a string we can live without the check but it is
seemingly an identifier so it is strange that it is not detected at
compile-time. I guess that it is the motivation for the check.
What makes the story complex is that connection matte
the way, as DECLARE is new as of v14, I think that the interactions
between DECLARE and the past queries qualify as an open item. I am
adding Michael Meskes in CC. I got to wonder how much of a
compatibility break it would be for DEALLOCATE and DESCRIBE to handle
EXEC SQL AT in a way more con
me to finish evaluating this patch, but it
seems that this moves to the right direction. The new warnings for
lookup_descriptor() and drop_descriptor() with the connection name are
useful. Should we have more cases with con2 in the new set of tests
for DESCRIBE?
--
Michael
signature.asc
Description: PGP signature
Dear Hackers,
I revised my patch.
> Please also ensure that you're generating the patch against git HEAD.
> The cfbot shows it as failing to apply, likely because you're looking
> at something predating ad8305a43d1890768a613d3fb586b44f17360f29.
Maybe there was something wrong with my local envir
"kuroda.hay...@fujitsu.com" writes:
>> The test portion bloats the patch so it would be easier to read if
>> that part is separated from the code part.
> Right, I'll separate and attach again few days. Sorry for inconvenience;-(.
Please also ensure that you're generating the patch against git HE
Dear Horiguchi-san,
Thank you for replying!
> (Maybe by consulting the code.. Anyway, )
I noticed the patch cannot be applied...
> The follwoing commands don't.
> DESCRIBE
> DEALLOCATE
> DECLARE CURSOR .. FOR
> CREATE TABLE AS EXECUTE
I'm not sure about `CREATE
At Thu, 01 Jul 2021 17:48:49 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 25 Jun 2021 12:02:22 +, "kuroda.hay...@fujitsu.com"
> wrote in
> The following commands handle the liked connection.
> DECLARE
> PREPARE
> EXECUTE
>
> The follwoing comma
At Fri, 25 Jun 2021 12:02:22 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Hackers,
>
> I checked about DECLARE STATEMENT(added from ad8305a), and I noticed that
> this connection-control feature cannot be used for DEALLOCATE and DESCRIBE
> statement.
>
>
Dear Hackers,
I checked about DECLARE STATEMENT(added from ad8305a), and I noticed that
this connection-control feature cannot be used for DEALLOCATE and DESCRIBE
statement.
I attached the patch that fixes these bugs, this contains source and test code.
How do you think?
Best Regards,
Hayato
On Wed, Sep 2, 2020 at 8:06 PM Tom Lane wrote:
> Please defend that claim. Otherwise this seems like a pretty
> random change.
I had seen that there is discrepancy in postgres --describe-config & the
value displayed from pg_settings like in the below case:
postgres=# select na
vignesh C writes:
> Postgres's describe-config option prints reset_val for int & real
> configuration parameters which is not useful as it is not updated.
Uh, what?
> Printing boot_val is better in this case.
Please defend that claim. Otherwise this seems like a pr
Hi,
Postgres's describe-config option prints reset_val for int & real
configuration parameters which is not useful as it is not updated.
Printing boot_val is better in this case. reset_val is updated with
boot_val while the server is getting started but in case of postgres
--describe-co
I'm not opposed to a DESCRIBE server-side
command, and others have shown some interest too. However, the thread
and commitfest entry at hand refer to a new psql command \describe,
which is completely unrelated. So I suggest we should close this CF
entry as Returned with Feedback, and wait unti
(
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-help-transact-sql?view=sql-server-2017
)
which contextually returns one of two different result sets (name, owner,
object type) or (column name, type, storage, length, precision, scale,
nullable, default, rule, col
On Sun, Jun 23, 2019 at 7:34 AM Corey Huinker wrote:
>> > So what is the uptake on implementing this at the server side, ie.
>> > DESCRIBE?
>>
>> I'm pretty skeptical of this idea, unless you are willing to throw
>> away at least one and possibly both of
>
> > So what is the uptake on implementing this at the server side, ie.
> > DESCRIBE?
>
> I'm pretty skeptical of this idea, unless you are willing to throw
> away at least one and possibly both of the following goals:
>
> 1. Compatibility with psql'
On Fri, Jun 21, 2019 at 05:49:43PM -0400, Alvaro Herrera wrote:
> On 2019-Jun-21, David Fetter wrote:
>
> > On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> > > On 2018-Jan-29, David Fetter wrote:
> > >
> > > > We could certainly have
Alvaro Herrera writes:
> On 2018-Jan-29, David Fetter wrote:
>> We could certainly have \d call DESCRIBE for later versions of the
>> server. \ commands which call different SQL depending on server
>> version have long been a standard practice.
> So what is the uptake
On 2019-Jun-21, David Fetter wrote:
> On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> > On 2018-Jan-29, David Fetter wrote:
> >
> > > We could certainly have \d call DESCRIBE for later versions of the
> > > server. \ commands which call
On Fri, Jun 21, 2019 at 05:20:54PM -0400, Alvaro Herrera wrote:
> On 2018-Jan-29, David Fetter wrote:
>
> > We could certainly have \d call DESCRIBE for later versions of the
> > server. \ commands which call different SQL depending on server
> > version have long
On 2018-Jan-29, David Fetter wrote:
> We could certainly have \d call DESCRIBE for later versions of the
> server. \ commands which call different SQL depending on server
> version have long been a standard practice.
So what is the uptake on implementing this at the server side, ie.
On Sat, May 18, 2019 at 1:17 AM Sergei Kornilov wrote:
> Hello
>
> No, this is not bug. This is expected beharior of search_path setting:
> https://www.postgresql.org/docs/current/runtime-config-client.html
>
> > Likewise, the current session's temporary-table schema, pg_temp_nnn, is
> always sea
Hello
No, this is not bug. This is expected beharior of search_path setting:
https://www.postgresql.org/docs/current/runtime-config-client.html
> Likewise, the current session's temporary-table schema, pg_temp_nnn, is
> always searched if it exists. It can be explicitly listed in the path by
>
Melanie Plageman writes:
> So, I noticed that if I make a table in one schema and then a table with the
> same name in another schema that describe only shows me one of them.
Yes, that's intended, psql's \d will only show you tables that are
visible in the search path, unle
So, I noticed that if I make a table in one schema and then a table with the
same name in another schema that describe only shows me one of them.
Demonstrating with temp table and regular table just for simplicity:
If I make a temp table t1 and a normal table t1 (it doesn't
matter which
Hi
> Since this is now waiting for v13, there's a bit more time to entertain
> the question of whether we'd rather have these in psql or in a new server
> command DESCRIBE [verbose] [system], and if so, whether the output of that
> would itself be query-able or not.
>
On Mon, Mar 4, 2019 at 1:45 PM Corey Huinker
wrote:
>
>>> - Tab completion for \descibe-verbose.
>>> I know that \d+ tab completion is also not there, but I think we must
>>> have tab completion for \descibe-verbose.
>>>
>>> postgres=# \
>
>
> I agree with Andres and Robert. This patch should be pushed to PG13.
>
> I'll do that on March 8 unless there is a compelling argument not to.
>
>
No objection. I'll continue to work on it, though.
On 2/25/19 9:44 PM, Robert Haas wrote:
On Sat, Feb 23, 2019 at 7:19 PM Andres Freund wrote:
Sure, but it was late, and we have far more patches than we can deal
with. Many of them much much older than this.
More importantly, at least in my opinion, is that this is one of those
questions that
>
>
>> - Tab completion for \descibe-verbose.
>> I know that \d+ tab completion is also not there, but I think we must
>> have tab completion for \descibe-verbose.
>>
>> postgres=# \describe-
>> \describe-extension
>> \describe-replication-publica
for \descibe-verbose.
> I know that \d+ tab completion is also not there, but I think we must have
> tab completion for \descibe-verbose.
>
> postgres=# \describe-
> \describe-extension
> \describe-replication-publication \describe-user-mapping
> \descri
1 - 100 of 147 matches
Mail list logo
