Kirill Reshke writes:
> On Wed, 4 Dec 2024 at 01:07, Tom Lane wrote:
>> I'm totally willing to throw that possibility overboard
>> permanently in order to expand the set of creatable object types
>> without introducing a ton of restrictions and weird behaviors.
>> What do you think?
> Im +1 on t
Looks like this thread does not move forward. So I'm posting my
thoughts to bump it.
On Wed, 4 Dec 2024 at 01:07, Tom Lane wrote:
> I'm totally willing to throw that possibility overboard
> permanently in order to expand the set of creatable object types
> without introducing a ton of restrictio
Peter Eisentraut writes:
> On 30.11.24 20:08, Tom Lane wrote:
>> ... I think we ought to nuke
>> that concept from orbit and just execute the schema elements in the
>> order presented. I looked at several iterations of the SQL standard
>> and cannot find any support for the idea that CREATE SCHEM
On 30.11.24 20:08, Tom Lane wrote:
2. transformCreateSchemaStmtElements is of the opinion that it's
responsible for ordering the schema elements in a way that will work,
but it just about completely fails at that task. Ordering the objects
by kind is surely not sufficient, and adding CREATE DOMA
On 02/12/2024 17:56, Tom Lane wrote:
Vik Fearing writes:
On 02/12/2024 03:15, Tom Lane wrote:
Also, if SQL intended to constrain the search path for unqualified
identifiers to be only the new schema, they'd hardly need a concept
of at all.
I looked up the original paper (MUN-051) that intr
Vik Fearing writes:
> On 02/12/2024 03:15, Tom Lane wrote:
>> Also, if SQL intended to constrain the search path for unqualified
>> identifiers to be only the new schema, they'd hardly need a concept
>> of at all.
> I looked up the original paper (MUN-051) that introduced the path specification
On 02/12/2024 03:15, Tom Lane wrote:
Michael Paquier writes:
If I'm parsing the spec right, the doc mentions in its 5)~6) of the
syntax rules in CREATE SCHEMA that non-schema-qualified objects should
use the new schema name defined in the CREATE SCHEMA query. So that
pretty much settles the
Michael Paquier writes:
> If I'm parsing the spec right, the doc mentions in its 5)~6) of the
> syntax rules in CREATE SCHEMA that non-schema-qualified objects should
> use the new schema name defined in the CREATE SCHEMA query. So that
> pretty much settles the rules to use when having a new obj
On Sun, Dec 01, 2024 at 05:30:20PM -0500, Tom Lane wrote:
> Which certainly begs the question of how smart their re-ordering
> algorithm is, or what they do about ambiguity between new and existing
> objects.
Perhaps because they are able to track efficiently all schema
references, like checking t
I wrote:
> I looked at DB2's reference page:
> https://www.ibm.com/docs/en/db2/11.5?topic=statements-create-schema
Oh, how did I forget Oracle?
https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/CREATE-SCHEMA.html
Theirs is restricted to CREATE TABLE, CREATE VIEW, and GRANT; als
jian he writes:
> On Sun, Dec 1, 2024 at 1:53 PM Tom Lane wrote:
>> (I'd be curious to know how other major implementations handle
>> this. Are we the only implementation that ever read the spec
>> that way?)
> quote from
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-
On Sun, Dec 1, 2024 at 1:53 PM Tom Lane wrote:
>
> Kirill Reshke writes:
> > 3) Why do we delete this in `create_schema.sgml`? Is this untrue? It
> > is about order of definition, not creation, isn't it?
>
> >> - The SQL standard specifies that the subcommands in CREATE
> >> - SCHEMA can appe
Kirill Reshke writes:
> 3) Why do we delete this in `create_schema.sgml`? Is this untrue? It
> is about order of definition, not creation, isn't it?
>> - The SQL standard specifies that the subcommands in CREATE
>> - SCHEMA can appear in any order.
In context with the following sentence, wha
On Sun, 1 Dec 2024 at 04:33, Tom Lane wrote:
> I looked at several iterations of the SQL standard
> and cannot find any support for the idea that CREATE SCHEMA needs to
> be any smarter than that. I'd also argue that doing anything else is
> a POLA violation. It's especially a POLA violation if
I wrote:
> 2. transformCreateSchemaStmtElements is of the opinion that it's
> responsible for ordering the schema elements in a way that will work,
> but it just about completely fails at that task. Ordering the objects
> by kind is surely not sufficient, and adding CREATE DOMAIN will make
> that
[ Looping in Peter E. for commentary on SQL-spec compatibility ]
I spent some time looking at this patch, and came away with
two main thoughts:
1. It doesn't make any sense to me to support CREATE DOMAIN within
CREATE SCHEMA but not any of our other commands for creating types.
It's not a consist
On Fri, 29 Nov 2024 at 18:47, jian he wrote:
>
> new patch, add tab complete for it.
Thank you. You may also be interested in reviewing [0].
[0]
https://www.postgresql.org/message-id/CALdSSPhqfvKbDwqJaY%3DyEePi_aq61GmMpW88i6ZH7CMG_2Z4Cg%40mail.gmail.com
--
Best regards,
Kirill Reshke
new patch, add tab complete for it.
From 91d05e547ca722d4537ff7420b8248a3fcce3b58 Mon Sep 17 00:00:00 2001
From: jian he
Date: Fri, 29 Nov 2024 21:44:54 +0800
Subject: [PATCH v5 1/1] support CREATE SCHEMA CREATE DOMAIN
SQL standard allow domain to be specified with CREATE SCHEMA
statement. This p
On Thu, 28 Nov 2024 at 10:52, Tom Lane wrote:
> No, I don't think this should be part of the patch discussed in this
> thread.
Ok, I created a separate thread for this.
How about this one? Do you think the suggested idea is good? Is it
worthwhile to do this, in your opinion?
--
Best regards,
Kirill Reshke writes:
> On Wed, 27 Nov 2024 at 23:39, Tom Lane wrote:
>> We've fixed a few utility statements so that they can receive
>> a passed-down ParseState, but not DefineDomain.
> PFA as an independent patch then. Or should we combine these two into one?
No, I don't think this should be
On Wed, 27 Nov 2024 at 23:39, Tom Lane wrote:
>
> Kirill Reshke writes:
> > On Wed, 27 Nov 2024 at 08:42, jian he wrote:
> >> CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
> >> create domain ss1 as ss
> >> create domain ss as text;
> >> ERROR: type "ss" does not exist
> >>
> >> the
Kirill Reshke writes:
> On Wed, 27 Nov 2024 at 08:42, jian he wrote:
>> CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
>> create domain ss1 as ss
>> create domain ss as text;
>> ERROR: type "ss" does not exist
>>
>> the error message seems not that OK,
>> if we can point out the erro
On Wed, 27 Nov 2024 at 08:42, jian he wrote:
>
> On Sat, Nov 23, 2024 at 1:19 PM jian he wrote:
> >
> > I didn't add a doc entry. I will do it later.
> hi
> attached patch with thorough tests and documentation.
>
Hi! Thanks for pushing this further.
> one issue i still have is:
> CREATE SCHEMA
jian he writes:
> one issue i still have is:
> CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
> create domain ss1 as ss
> create domain ss as text;
> ERROR: type "ss" does not exist
> the error message seems not that OK,
> if we can point out the error position, that would be great
On Sat, Nov 23, 2024 at 1:19 PM jian he wrote:
>
> I didn't add a doc entry. I will do it later.
hi
attached patch with thorough tests and documentation.
one issue i still have is:
CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
create domain ss1 as ss
create domain ss as text;
ERRO
On Tue, Nov 12, 2024 at 8:55 PM Kirill Reshke wrote:
>
> Patch obviously leaks doc & regression tests, but I'm posting it to
> see if this contribution is needed in PostgreSQL
the following two statement should fail:
CREATE SCHEMA regress_schema_2 AUTHORIZATION CURRENT_ROLE
CREATE table t(a ss)
Hi hackers!
This copy of my reply mail from pgsql-general[0], & [1] which was held
for moderation for some reason.
Here it goes as-is :
== begin
Hi Álvaro, thanks for the detailed explanation.
So, IIUC you are suggesting to support SQL standard features before
any work with PostgreSQL extension
27 matches
Mail list logo
