Re: CREATE TABLE IF NOT EXISTS AS

Hackers,

Co-worker asked a question I could not answer: Why is IF NOT EXISTS not supported by CREATE TABLE AS? Oversight, perhaps? Or maybe because one expects the table to have the data from the SELECT statement? If the latter, maybe OR REPLACE would be useful?

Best,

David

"David E. Wheeler" <david(at)justatheory(dot)com> writes:
> Co-worker asked a question I could not answer: Why is IF NOT EXISTS not supported by CREATE TABLE AS?

That's an even worse idea than plain CREATE IF NOT EXISTS (which was
put in over vocal objections from me and some other people). Not only
would you not have the faintest clue as to the properties of the table
afterwards, but no clue as to its contents either.

regards, tom lane

On Nov 16, 2013, at 4:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>> Co-worker asked a question I could not answer: Why is IF NOT EXISTS not supported by CREATE TABLE AS?
>
> That's an even worse idea than plain CREATE IF NOT EXISTS (which was
> put in over vocal objections from me and some other people). Not only
> would you not have the faintest clue as to the properties of the table
> afterwards, but no clue as to its contents either.

You mean that, after running it, one cannot tell whether or not a new table was created or not without looking at it? I guess that makes sense, though sometimes I like to tell the system to assume that I know what I’m doing -- e.g., that either outcome works for me.

Not essential as a core feature, mind you; I can use DO to accomplish the same thing. It’s just a bit more work that way. And perhaps that’s for the best.

Best,

David

On Sun, Nov 17, 2013 at 6:05 PM, David E. Wheeler <david(at)justatheory(dot)com>wrote:

> On Nov 16, 2013, at 4:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> >> Co-worker asked a question I could not answer: Why is IF NOT EXISTS not
> supported by CREATE TABLE AS?
> >
> > That's an even worse idea than plain CREATE IF NOT EXISTS (which was
> > put in over vocal objections from me and some other people). Not only
> > would you not have the faintest clue as to the properties of the table
> > afterwards, but no clue as to its contents either.
>
> You mean that, after running it, one cannot tell whether or not a new
> table was created or not without looking at it? I guess that makes sense,
> though sometimes I like to tell the system to assume that I know what I’m
> doing -- e.g., that either outcome works for me.
>
> Not essential as a core feature, mind you; I can use DO to accomplish the
> same thing. It’s just a bit more work that way. And perhaps that’s for the
> best.
>
>
I'm planning to implement it for the next commit fest (2014-01)...

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello

On Mon, 2013-11-18 at 11:16 -0200, Fabrízio de Royes Mello wrote:
> I'm planning to implement it for the next commit fest (2014-01)...

This email was registered in the commit fest as a patch, but contains no
patch and you indicate that it belongs in different commit fest. Please
sort that out.

On Wed, Nov 20, 2013 at 2:10 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
> On Mon, 2013-11-18 at 11:16 -0200, Fabrízio de Royes Mello wrote:
> > I'm planning to implement it for the next commit fest (2014-01)...
>
> This email was registered in the commit fest as a patch, but contains no
> patch and you indicate that it belongs in different commit fest. Please
> sort that out.
>

Sorry, I registered the wrong message-id. Fixed.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello

On 11/17/2013 08:40 AM, Tom Lane wrote:
> That's an even worse idea than plain CREATE IF NOT EXISTS (which was
> put in over vocal objections from me and some other people).

I'm pretty uncomfortable with CREATE TABLE IF NOT EXISTS too - but it
doesn't hurt someone who doesn't use it and it does have uses.

We have plenty of other features that can be horribly abused too. That
doesn't mean new ones should be added casually, just that it's sometimes
appropriate to accept something that's imperfect when it meets a need
and we don't have a better way to do it.

It'd be great if there was a sane way to implement "CREATE OR REPLACE
TABLE" - since that's what people really want a lot of the time. "Ensure
that at the end of this command the table looks like this". There's just
no sane way to do that for a non-empty table.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2013/11/20 Craig Ringer <craig(at)2ndquadrant(dot)com>

> On 11/17/2013 08:40 AM, Tom Lane wrote:
> > That's an even worse idea than plain CREATE IF NOT EXISTS (which was
> > put in over vocal objections from me and some other people).
>
> I'm pretty uncomfortable with CREATE TABLE IF NOT EXISTS too - but it
> doesn't hurt someone who doesn't use it and it does have uses.
>
> We have plenty of other features that can be horribly abused too. That
> doesn't mean new ones should be added casually, just that it's sometimes
> appropriate to accept something that's imperfect when it meets a need
> and we don't have a better way to do it.
>
> It'd be great if there was a sane way to implement "CREATE OR REPLACE
> TABLE" - since that's what people really want a lot of the time. "Ensure
> that at the end of this command the table looks like this". There's just
> no sane way to do that for a non-empty table.
>

I disagree - CREATE OR REPLACE FUNCTION has sense, because new function can
has same interface (and will be overwriten) or different (and there will be
two functions). So with CREATE OR REPLACE TABLE there are two new questions
- has to new table respect original interface and what about content? I
don't think so CREATE OR REPLACE TABLE is good idea.

Regards

Pavel

>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

On 11/20/2013 03:41 PM, Pavel Stehule wrote:
>
> It'd be great if there was a sane way to implement "CREATE OR REPLACE
> TABLE" - since that's what people really want a lot of the time. "Ensure
> that at the end of this command the table looks like this". There's just
> no sane way to do that for a non-empty table.
>
>
> I disagree - CREATE OR REPLACE FUNCTION has sense, because new function
> can has same interface (and will be overwriten) or different (and there
> will be two functions). So with CREATE OR REPLACE TABLE there are two
> new questions - has to new table respect original interface and what
> about content? I don't think so CREATE OR REPLACE TABLE is good idea.

Er, that's what I was saying. It'd be great if it were possible to do it
sanely, but it isn't.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services