Re: Adding SHOW CREATE TABLE

On Fri, Jun 30, 2023 at 1:56 PM Kirk Wolak wrote: > On Wed, Jun 21, 2023 at 8:52 PM Kirk Wolak wrote: > >> On Mon, Jun 5, 2023 at 7:43 AM Jelte Fennema wrote: >> >>> On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: >>> >> Definitely have the questions from the previous email, but I CERTAINLY app

Re: Adding SHOW CREATE TABLE

On Wed, Jun 21, 2023 at 8:52 PM Kirk Wolak wrote: > On Mon, Jun 5, 2023 at 7:43 AM Jelte Fennema wrote: > >> On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: >> > Can this get turned into a Patch? Were you offering this code up for >> others (me?) to pull, and work into a patch? >> > [If I do th

Re: Adding SHOW CREATE TABLE

On Mon, Jun 5, 2023 at 7:43 AM Jelte Fennema wrote: > On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: > > Can this get turned into a Patch? Were you offering this code up for > others (me?) to pull, and work into a patch? > > [If I do the patch, I am not sure it gives you the value of reducing >

Re: Adding SHOW CREATE TABLE

On Thu, 1 Jun 2023 at 18:57, Kirk Wolak wrote: > Can this get turned into a Patch? Were you offering this code up for others > (me?) to pull, and work into a patch? > [If I do the patch, I am not sure it gives you the value of reducing what > CITUS has to maintain. But it dawns on > me that yo

Re: Adding SHOW CREATE TABLE

On Thu, Jun 1, 2023 at 4:46 PM Andrew Dunstan wrote: > On 2023-06-01 Th 16:39, Kirk Wolak wrote: > > On Thu, Jun 1, 2023 at 3:13 PM Andrew Dunstan wrote: > >> On 2023-06-01 Th 12:57, Kirk Wolak wrote: >> >> PS: It dawned on me that if pg_dump had used server side code to generate >> its DDL, its

Re: Adding SHOW CREATE TABLE

On 2023-06-01 Th 16:39, Kirk Wolak wrote: On Thu, Jun 1, 2023 at 3:13 PM Andrew Dunstan wrote: On 2023-06-01 Th 12:57, Kirk Wolak wrote: PS: It dawned on me that if pg_dump had used server side code to generate its DDL, its complexity would drop. Maybe, that remains to be s

Re: Adding SHOW CREATE TABLE

On Thu, Jun 1, 2023 at 3:13 PM Andrew Dunstan wrote: > On 2023-06-01 Th 12:57, Kirk Wolak wrote: > > PS: It dawned on me that if pg_dump had used server side code to generate > its DDL, its complexity would drop. > > Maybe, that remains to be seen. pg_dump needs to produce SQL that is > suitable

Re: Adding SHOW CREATE TABLE

On 2023-06-01 Th 12:57, Kirk Wolak wrote: PS: It dawned on me that if pg_dump had used server side code to generate its DDL, its complexity would drop. Maybe, that remains to be seen. pg_dump needs to produce SQL that is suitable for the target database, not the source database. cheers

Re: Adding SHOW CREATE TABLE

odebase: > > https://github.com/citusdata/citus/blob/main/src/backend/distributed/deparser/citus_ruleutils.c > > I'm pretty sure we'd be happy to upstream those if that meant, we > wouldn't have to update them for every postgres release. > > We also have the master_get_tab

Re: Adding SHOW CREATE TABLE

/blob/main/src/backend/distributed/deparser/citus_ruleutils.c I'm pretty sure we'd be happy to upstream those if that meant, we wouldn't have to update them for every postgres release. We also have the master_get_table_ddl_events UDF, which does what SHOW CREATE TABLE would do. S

Re: Adding SHOW CREATE TABLE

parser/citus_ruleutils.c I'm pretty sure we'd be happy to upstream those if that meant, we wouldn't have to update them for every postgres release. We also have the master_get_table_ddl_events UDF, which does what SHOW CREATE TABLE would do.

Re: Adding SHOW CREATE TABLE

On 2023-05-22 Mo 05:24, Pavel Stehule wrote: po 22. 5. 2023 v 7:19 odesílatel Kirk Wolak napsal: On Fri, May 19, 2023 at 1:08 PM Andrew Dunstan wrote: I think the ONLY place we should have this is in server side functions. More than ten years ago I did some work in

Re: Adding SHOW CREATE TABLE

po 22. 5. 2023 v 7:19 odesílatel Kirk Wolak napsal: > On Fri, May 19, 2023 at 1:08 PM Andrew Dunstan > wrote: > >> I think the ONLY place we should have this is in server side functions. >> More than ten years ago I did some work in this area (see below), but it's >> one of those things that hav

Re: Adding SHOW CREATE TABLE

On Fri, May 19, 2023 at 1:08 PM Andrew Dunstan wrote: > I think the ONLY place we should have this is in server side functions. > More than ten years ago I did some work in this area (see below), but it's > one of those things that have been on my ever growing personal TODO list > > See

Re: Adding SHOW CREATE TABLE

On Sat, May 20, 2023 at 2:33 PM Stephen Frost wrote: > Greetings, > > On Sat, May 20, 2023 at 13:32 David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Sat, May 20, 2023 at 10:26 AM Stephen Frost >> wrote: >> >>> > A server function can be conveniently called from any client code. >

Re: Adding SHOW CREATE TABLE

Greetings, On Sat, May 20, 2023 at 13:32 David G. Johnston wrote: > On Sat, May 20, 2023 at 10:26 AM Stephen Frost wrote: > >> > A server function can be conveniently called from any client code. >> >> Clearly any client using libpq can conveniently call code which is in >> libpq. >> > > Clearl

Re: Adding SHOW CREATE TABLE

"David G. Johnston" writes: > On Sat, May 20, 2023 at 10:26 AM Stephen Frost wrote: >> Clearly any client using libpq can conveniently call code which is in >> libpq. > Clearly there are clients that don't use libpq. JDBC comes to mind. Yeah. I'm also rather concerned about the bloat factor;

Re: Adding SHOW CREATE TABLE

On Sat, May 20, 2023 at 10:26 AM Stephen Frost wrote: > > A server function can be conveniently called from any client code. > > Clearly any client using libpq can conveniently call code which is in > libpq. > > Clearly there are clients that don't use libpq. JDBC comes to mind. David J.

Re: Adding SHOW CREATE TABLE

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Fri, 2023-05-19 at 13:08 -0400, Andrew Dunstan wrote: > > On 2023-05-18 Th 19:53, Stephen Frost wrote: > > > * Kirk Wolak (wol...@gmail.com) wrote: > > > > My approach for now is to develop this as the \st command. > > > > After revi

Re: Adding SHOW CREATE TABLE

cket.org/adunstan/retailddl/src/master/> and <https://www.youtube.com/watch?v=fBarFKOL3SI> I have my own implementation of SHOW CREATE as a ddlx extension available at https://github.com/lacanoid/pgddl Far from perfect but getting better and it seems good enough to be used by some people... Ž.

Re: Adding SHOW CREATE TABLE

On Fri, 2023-05-19 at 13:08 -0400, Andrew Dunstan wrote: > On 2023-05-18 Th 19:53, Stephen Frost wrote: > > * Kirk Wolak (wol...@gmail.com) wrote: > > > My approach for now is to develop this as the \st command. > > > After reviewing the code/output from the 3 sources (psql, fdw, and > > > pg_dump)

Re: Adding SHOW CREATE TABLE

nstan/retailddl/src/master/> > <https://bitbucket.org/adunstan/retailddl/src/master/> and > <https://www.youtube.com/watch?v=fBarFKOL3SI> > <https://www.youtube.com/watch?v=fBarFKOL3SI> > > > > Some additional backstory, as this has come up before... A direction dis

Re: Adding SHOW CREATE TABLE

On 2023-05-18 Th 19:53, Stephen Frost wrote: Greetings, * Kirk Wolak (wol...@gmail.com) wrote: My approach for now is to develop this as the \st command. After reviewing the code/output from the 3 sources (psql, fdw, and pg_dump). This trivializes the approach, and requires the smallest set o

Re: Adding SHOW CREATE TABLE

Greetings, * Kirk Wolak (wol...@gmail.com) wrote: > My approach for now is to develop this as the \st command. > After reviewing the code/output from the 3 sources (psql, fdw, and > pg_dump). This trivializes the approach, > and requires the smallest set of changes (psql is already close with > e

Re: Adding SHOW CREATE TABLE

On Sun, May 14, 2023 at 2:20 AM Kirk Wolak wrote: > On Sat, May 13, 2023 at 3:34 PM Jeremy Smith > wrote: > >> >> >> On Sat, May 13, 2023, 3:25 AM Kirk Wolak wrote: >> >>> Does this imply SQL SYNTAX like: >>> >>> SHOW

Re: psql: add \si, \sm, \st and \sr functions to show CREATE commands for indexes, matviews, triggers and tables

On 18.08.2020 17:25, Tom Lane wrote: a.pervush...@postgrespro.ru writes: [ si_st_sm_sr_v2.patch ] I hadn't particularly noticed this thread before, but I happened to look through this patch, and I've got to say that this proposed feature seems like an absolute disaster from a maintenance standp

Re: psql: add \si, \sm, \st and \sr functions to show CREATE commands for indexes, matviews, triggers and tables

a.pervush...@postgrespro.ru writes: > [ si_st_sm_sr_v2.patch ] I hadn't particularly noticed this thread before, but I happened to look through this patch, and I've got to say that this proposed feature seems like an absolute disaster from a maintenance standpoint. There will be no value in an \s

Re: psql: add \si, \sm, \st and \sr functions to show CREATE commands for indexes, matviews, triggers and tables

Anna Akenteva wrote 2020-08-11 13:37: About the patch: 1) There is some code duplication for the exec_command_[sm|si|st|sr] functions. Plus, it seems weird to separate sm (show matview) from sv (show view). Perhaps it would be more convenient to combine some of the code? Maybe by editing the alr

Re: psql: add \si, \sm, \st and \sr functions to show CREATE commands for indexes, matviews, triggers and tables

On 2020-07-28 20:46, a.pervush...@postgrespro.ru wrote: I've attached a patch that implements \si, \sm, \st and \sr functions that show the CREATE command for indexes, matviews, triggers and tables. The functions are implemented similarly to the existing sf/sv functions with some modifications.

psql: add \si, \sm, \st and \sr functions to show CREATE commands for indexes, matviews, triggers and tables

Hi, I've attached a patch that implements \si, \sm, \st and \sr functions that show the CREATE command for indexes, matviews, triggers and tables. The functions are implemented similarly to the existing sf/sv functions with some modifications. For triggers, I've decided to change input forma

Re: SHOW CREATE

On Fri, Jul 5, 2019 at 1:14 PM Corey Huinker wrote: > I'd like to hear what others have to say, and incorporate that feedback into > a follow up proposal. I am unclear how this could be implemented without ending up with a ton of extra code that has to be maintained. pg_dump is a client-side to

Re: SHOW CREATE

and bolts of a given database object. > > 2. A desire to essentially make the schema portion of pg_dump a server side > > command. > > > > To that end, I see splitting this into two commands, SHOW CREATE > > and SHOW DUMP. > > I like the idea of having these fe

Re: SHOW CREATE

p a server side > command. > > To that end, I see splitting this into two commands, SHOW CREATE and SHOW > DUMP. I like the idea of having these features available via SQL as opposed to separate tools. Is it necessary to have specific commands for them? It seems they would potential

Re: SHOW CREATE

desire to see the underlying nuts and bolts of a given database object. 2. A desire to essentially make the schema portion of pg_dump a server side command. To that end, I see splitting this into two commands, SHOW CREATE and SHOW DUMP. SHOW DUMP would the original command minus the object type and obj

SHOW CREATE

rom b1bbf5884da2ba329418d73e2b993edda8971926 Mon Sep 17 00:00:00 2001 From: coreyhuinker Date: Sun, 30 Jun 2019 18:22:14 -0400 Subject: [PATCH v1] first draft of SHOW CREATE To: hackers MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2.21.0" This is a multi-part me