On Mon, 2025-08-18 at 09:57 -0400, Tom Lane wrote:
> Jelte Fennema-Nio writes:
>
> > I have wanted this MANY times. I've had this as a PG user: I think
> > it's literally the first thing I did when connecting to a Postgres
> > server the first time. Coming from MySQL, I wanted to see the exact
>
On Sat, Aug 16, 2025 at 4:23 PM Tom Lane wrote:
>
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
> > On 2025-Aug-16, Kirill Reshke wrote:
> >> After putting some more thought into it, maybe we can implement the
> >> whole thing as contrib extension? This would be the most Postgres-y
> >> way to me.
>
On Mon, 18 Aug 2025 at 10:32, Andrew Dunstan wrote:
> > But the real issue is what to print. In the case of a table, should
> > we also show its indexes? What about foreign keys to or from other
> > tables? If it's a partitioned table, what about the partitions?
> > I'm not sure this is as si
On 2025-08-18 Mo 10:39 AM, Isaac Morland wrote:
On Mon, 18 Aug 2025 at 10:32, Andrew Dunstan wrote:
> But the real issue is what to print. In the case of a table, should
> we also show its indexes? What about foreign keys to or from other
> tables? If it's a partitioned table, w
On 2025-08-18 Mo 9:57 AM, Tom Lane wrote:
Jelte Fennema-Nio writes:
On Sat, 16 Aug 2025 at 16:23, Tom Lane wrote:
So I don't really buy Álvaro's argument above. It'd be better
to design to some concrete requirement that isn't either of
those. Unfortunately, it's not clear to me that anyon
On Mon, 18 Aug 2025 at 15:57, Tom Lane wrote:
> You haven't actually defined what "this" is. For starters, do you
> really want this output to be included in \d? Seems like one part
> or the other of such output would be clutter, so I'd be more minded
> to leave \d alone and invent some new comm
Jelte Fennema-Nio writes:
> On Sat, 16 Aug 2025 at 16:23, Tom Lane wrote:
>> So I don't really buy Álvaro's argument above. It'd be better
>> to design to some concrete requirement that isn't either of
>> those. Unfortunately, it's not clear to me that anyone has
>> a concrete use-case in mind
On Sat, 16 Aug 2025 at 16:23, Tom Lane wrote:
> So I don't really buy Álvaro's argument above. It'd be better
> to design to some concrete requirement that isn't either of
> those. Unfortunately, it's not clear to me that anyone has
> a concrete use-case in mind that isn't either of those.
I ha
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> On 2025-Aug-16, Kirill Reshke wrote:
>> After putting some more thought into it, maybe we can implement the
>> whole thing as contrib extension? This would be the most Postgres-y
>> way to me.
> If we do that, then core tools such as psql or pg_dump can n
Hello Ziga,
On 2025-Aug-14, Ziga wrote:
> Of particular note is using oids only (no classid) to specify objects. I
> used believe that oid are unique across a postgres database for catalog
> objects, but since postgres 14 this no longer the case, see:
> https://github.com/lacanoid/pgddl/issues/25
On 2025-Aug-16, Kirill Reshke wrote:
> After putting some more thought into it, maybe we can implement the
> whole thing as contrib extension? This would be the most Postgres-y
> way to me.
If we do that, then core tools such as psql or pg_dump can never depend
on them. -1 from me.
--
Álvaro H
On Sat, 16 Aug 2025 at 10:08, I wrote:
> On Thu, 14 Aug 2025 at 23:30, Andrew Dunstan wrote:
> > Builtin
> > functions are also likely to be faster.
>
> We are not actually aiming for speed here, aren’t we?
I want to clarify here: I do not think consuming limiter resources of
catalog OID for buil
Hi!
On Thu, 14 Aug 2025 at 23:30, Andrew Dunstan wrote:
>
> Interesting. I think there are good reasons to have this as builtin
> functions, though, not least that it would allow us to base some psql
> meta-commands on it, or possibly an SQL command (DESCRIBE ?).
DESCRIBE would be confusing with
On 2025-08-13 We 10:29 PM, Ziga wrote:
Hi Andrew,
On 24/07/2025 22:26, Andrew Dunstan wrote:
Some years ago I gave a talk about $subject, but somehow it dropped
off my radar. Now I'm looking at it again. The idea is to have a
function (or set of functions) that would allow the user to get th
Hi Andrew,
On 24/07/2025 22:26, Andrew Dunstan wrote:
Some years ago I gave a talk about $subject, but somehow it dropped
off my radar. Now I'm looking at it again. The idea is to have a
function (or set of functions) that would allow the user to get the
DDL for any database object. Obviously
Hi,
On Jul 25, 2025 at 21:35 +0800, Tom Lane , wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
> > Reproducing a table might need multiple commands. Do you intend to
> > return a single string containing multiple semicolon-separated commands,
> > or are you thinking in a RETURNS SETOF where eac
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> Reproducing a table might need multiple commands. Do you intend to
> return a single string containing multiple semicolon-separated commands,
> or are you thinking in a RETURNS SETOF where each row contains a single
> command?
In the same vein: would we
On 2025-07-25 Fr 4:34 AM, Álvaro Herrera wrote:
On 2025-Jul-24, Andrew Dunstan wrote:
Obviously we already have some functions for things like views and
triggers, but most notably we don't have one for tables, something users
have long complained about. I have been trying to think of a reason
A related improvement would be to also support
CREATE EXTENSION psql;
To make at least the `\d ...` commands available to any client
And while we are at it, why not also
CREATE EXTENSION pgbench;
To make the fancy random distribution functions (at least) from
pgbench available from inside the
I have been thinking of this from a little different direction. We
already have all the needed functionality in pg_dump so why not just
have an option to do
CREATE EXTENSION pg_dump;
Which would wrap and expose whatever the current version of pg_dump is doing.
It still would need to resolve the
On 2025-Jul-24, Andrew Dunstan wrote:
> Obviously we already have some functions for things like views and
> triggers, but most notably we don't have one for tables, something users
> have long complained about. I have been trying to think of a reasonable
> interface for a single function, where w
Hi Andrew,
On Fri, Jul 25, 2025 at 1:56 AM Andrew Dunstan wrote:
>
> Some years ago I gave a talk about $subject, but somehow it dropped off
> my radar. Now I'm looking at it again. The idea is to have a function
> (or set of functions) that would allow the user to get the DDL for any
> database
On Fri, Jul 25, 2025 at 9:23 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > OTOH, we can have a common function and pass object type as parameter
> > i.e. select pg_get_ddl('table', 'mytable'), with this the same
> > function can be extended for different object types.
>
> And you'll work regclas
Dilip Kumar writes:
> OTOH, we can have a common function and pass object type as parameter
> i.e. select pg_get_ddl('table', 'mytable'), with this the same
> function can be extended for different object types.
And you'll work regclass/regtype/etc into that how? AFAICS the
only way would involv
On Fri, Jul 25, 2025 at 3:06 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > I have been trying to think
> > of a reasonable interface for a single function, where we would pass in,
> > say, a catalog oid plus an object oid, and maybe some optional extra
> > arguments. That seems a bit fra
Andrew Dunstan writes:
> I have been trying to think
> of a reasonable interface for a single function, where we would pass in,
> say, a catalog oid plus an object oid, and maybe some optional extra
> arguments. That seems a bit fragile, though. The alternative is that we
> have a separat
On Thu, 24 Jul 2025 at 21:46, Matheus Alcantara
wrote:
>
> On Thu Jul 24, 2025 at 5:26 PM -03, Andrew Dunstan wrote:
> > Some years ago I gave a talk about $subject, but somehow it dropped off
> > my radar. Now I'm looking at it again. The idea is to have a function
> > (or set of functions) that
On Thu Jul 24, 2025 at 5:26 PM -03, Andrew Dunstan wrote:
> Some years ago I gave a talk about $subject, but somehow it dropped off
> my radar. Now I'm looking at it again. The idea is to have a function
> (or set of functions) that would allow the user to get the DDL for any
> database object.
On Thu, 24 Jul 2025 at 16:26, Andrew Dunstan wrote:
> Some years ago I gave a talk about $subject, but somehow it dropped off
> my radar. Now I'm looking at it again. The idea is to have a function
> (or set of functions) that would allow the user to get the DDL for any
> database object. Obvious
29 matches
Mail list logo
